Является ли хорошей практикой иметь статические переменные для хранения глобальной изменяющейся информации?

Question

Является ли хорошей практикой ООП иметь статические переменные для хранения глобальной изменяющейся информации, необходимой различным классам?

, в отличие от передачи параметров, чтобы к ним могли обращаться вызываемые классы.

Answer 1

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

Некоторые аспекты, такие как ведение журнала, обычно реализуются следующим образом, но я бы имел тенденцию стараться не делать этого. Внедрение зависимостей делает жизнь намного проще с точки зрения тестирования. (Это может стать болезненным, когда вам нужно передать зависимость классу Foo только для того, чтобы передать ее в Bar, который затем передает ее в Baz и т. Д. Я думаю, что мы все еще не совсем «там» с точки зрения внедрения зависимости. I думаю, что что-то более продвинутое в области видимости / жизненного цикла было бы полезно как часть языка, но мы увидим ... Я не вижу, чтобы это происходило в самом C #, заметьте.

Answer 2

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

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

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

Answer 3

статическая переменная обычно используется для представления фиксированного значения с final подобно

public final static String JANUARY="january";

Answer 4

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

Однако это не будетхороший ООП.

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

Но для частных методов *Методы 1008 * или , вызываемые из нескольких мест для одинаковой функциональности , будет хорошей практикой сохранять статичность методов, и FxCop рекомендует то же самое.

Answer 5

Нет, постарайтесь обеспечить как можно более слабую связь.Если вы хотите, чтобы ваш код выполнялся как единое целое, то обмен глобальной информацией с использованием статических переменных настоятельно не рекомендуется.Тем не менее, вы можете постоянные значения с ними.Но тогда Enums есть в Java.Поэтому я бы порекомендовал их не использовать.

Answer 6

Я считаю, что лучше использовать файлы * .properties, которые содержат все настраиваемые параметры.Также вы можете реализовать синглетоноподобный класс *Configurator, который загрузит все параметры в ваше приложение.

Существует множество библиотек с открытым исходным кодом, которые могут помочь вам управлять параметрами приложения.В случае Java: http://commons.apache.org/configuration/index.html

Answer 7

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

Answer 8

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

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

Answer 9

Объединение их в некоторые виды классов свойств и их реализация в виде синглетонов будет приемлемой практикой ООП.