Альтернатива библиотекам статических классов

У меня есть большая коллекция статических классов Utility, которые содержат очень общие статические методы. Например, у меня есть класс CollectionUtility, в котором есть такие полезные методы, как:

общедоступная статическая пустота RemoveDuplicates (коллекция ICollection) ... и т. д.

В C # 3.0 я преобразовал их в методы расширения.

Я слышал некоторые разговоры о том, что в приложениях «корпоративного уровня» часто считается лучшей практикой избегать использования больших библиотек этих статических классов и методов. Я полагаю, что это может быть довольно сложно поддерживать.

Вопрос к тем из вас, кто работает над крупными корпоративными проектами для крупных компаний - поддерживаете ли вы библиотеки подобных служебных классов или нет? Что ты?


class c# static
person cbp    schedule 08.10.2008    source источник
comment
Пометьте вопросы, относящиеся к конкретному языку, с помощью языка.   -  person camh    schedule 09.10.2008
comment
Нитпик: C # 3.5 не существует. Обратитесь к C # 3.0 или .NET 3.5 или к обоим.   -  person Jon Skeet    schedule 09.10.2008

Ответы (4)


arrow_upward
1
arrow_downward

Вы говорите о коде, который будет частью общей библиотеки. Статические методы действительно используются в общих библиотеках. Проверьте System.Linq.Enumerable

Я бы следовал этим рекомендациям:

  • По умолчанию это не статические методы. Это должны быть только статические методы, потому что они, естественно, не имеют состояния (поведение зависит только от параметров). Если они не имеют естественного состояния без состояния, тогда вам следует создать соответствующий класс для управления этим состоянием.
  • Покройте их с помощью модульных тестов. Если вы не проводите модульное тестирование чего-либо еще, выполните модульное тестирование этих файлов. Это должно быть очень легко сделать. Если это непросто, значит, это неправильно.

Если вам нравится внедрение зависимостей, вы все равно можете это сделать. Код, основанный на статическом методе, может вместо этого вызывать Func (T, U) или действие, которое ссылается на этот статический метод.

person Amy B    schedule 09.10.2008

arrow_upward
0
arrow_downward

Точно нет. Служебные модули со временем превращаются в большие коллекции грубого кода.

person 1800 INFORMATION    schedule 08.10.2008

arrow_upward
0
arrow_downward

Я обычно помещаю такие вещи, как конфигурация и константы, только в одноэлементный или статический класс, потому что он никогда не изменится и с таким же успехом может быть «глобальным».

person mannu    schedule 08.10.2008
comment
Конфигурация никогда не изменится?!? -1 Нет тебе супа. - person Amy B; 09.10.2008
comment
Думаю, я не был достаточно ясным. Я имею в виду значения, которые никогда не изменятся в жизненном цикле приложения, например свойства для получения значений из web.config. - person mannu; 10.10.2008
comment
Я поддержу тебя из страны негатива, друг - person joelc; 16.09.2016

arrow_upward
0
arrow_downward

Я слышал некоторые разговоры о том, что в приложениях «корпоративного уровня» часто считается лучшей практикой избегать использования больших библиотек этих статических классов и методов. Я полагаю, что это может быть довольно сложно поддерживать.

IMHO, вы должны применять такие вещи, как дженерики, чтобы сократить размер ваших служебных методов / библиотек, и если вы используете служебный метод только в одном месте, то он не принадлежит общей библиотеке, но в конце дня у вас все еще, вероятно, будет довольно много.

Во всяком случае, это меня озадачивает. Если бы вы не поместили их в общую библиотеку, куда бы вы их поместили? Копировать / вставлять в каждый проект или что-то в этом роде?

person Orion Edwards    schedule 09.10.2008