Когда начинать статические классы?

Question

Всякий раз, когда я кодирую решение чего-то, я стараюсь либо использовать множество статических классов, либо вообще ничего. Например, в недавнем проекте мне пришлось отправить класс с некоторыми данными string/bool/datetime через несколько обручей, и единственным элементом, который не был статичным, был этот класс хранения данных. Все остальное (3 довольно классных класса с различными обязанностями по обработке) были статическими.

Я думаю, что я прошу здесь, это какой-то ввод, когда (и почему) я должен избегать использования статических классов для этих «процессов X, вывод Y». Можно ли всегда использовать их, пока они работают, или я стреляю себе в ногу относительно масштабируемости, поддержки плагинов и т. Д.?

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

Answer 1

НЕПОДВИЖНЫ два вопроса остаются немного одинаковыми. Моя основная забота о статических классах - наследование и доступность.

При использовании статического класса (публичный в худшем случае) каждый может получить доступ к вашим процессам и функциям. Который в большинстве случаев не то, что вы хотите. Для некоторых объектов слишком легко добраться до ваших функций и внести некоторые изменения. Таким образом, инъекция зависимости хороша в использовании. (Передайте объект, который вы хотите изменить в параметрах, в данном случае ваш process-object).

Чтобы не допустить, чтобы другие манипулировали вашим process-object, почему бы не попытаться использовать какой-то одноэлементный шаблон (или даже шаблон ex-singleton), так что на самом деле есть реальный объект для общения? Вы можете передать объект в параметры своих функций, если что-то нужно изменить. И тогда у вас может быть только один менеджер, который держит ваш process-object. Другие не должны попасть на объект.

Статические классы также трудно унаследовать. Переопределение статических методов кажется немного странным. Поэтому, если вы уверены, что процесс не будет единственным процессом, а некоторые более конкретные процессы будут созданы вами, то следует избегать и статического класса.

Answer 2

Статические классы обычно используются для небольших контейнеров данных и общих методов. Он не должен содержать больших данных до тех пор, пока это не потребуется. Эти классы не являются расширяемыми.

Answer 3

Большая часть кода я пишу:

• Использование инъекции зависимостей/IoC
• И должно быть mockable/проверяемым

Так я просто использовать объекты для почти все.

Я до сих пор использую статику для таких вещей, как:

• метода расширения
• Константы
• метода Helper/Utility (предварительные методы расширения)
• методы оператора

Answer 4

Я бы порекомендовал вам использовать метод как статический, если он имеет только один метод.В этом случае создание экземпляра класса вряд ли имеет смысл

У вас могут быть статические свойства, если вы хотите, чтобы поле действовало как global variable. Это шаблон проектирования, который соответствует Singleton pattern

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

За все остальное связанное с моей работой объектов путь (с небольшими исключениями), очевидно

Answer 5

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

Answer 6

Основная проблема, которую я вижу с использованием статических классов, как вы описываете, заключается в том, что зависимости жестко связаны. Если класс A должен использовать функции класса B, он должен явно знать об этом, что приводит к жесткой связи.

Хотя это не всегда проблема, так как ваш код растет, вам может быть сложнее изменить поведение программы для удовлетворения новых требований. Например, если вы хотите настроить поведение программы, это будет сложно, потому что для этого потребуется явный if/switch в коде. В противном случае вы могли бы просто сделать класс зависимым от интерфейса и swap-реализации.

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

Answer 7

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