Являются ли статические методы плохой практикой? [Дубликат]

Эта ссылка http://java.dzone.com/articles/why-static-bad-and-how-avoid , похоже, противоречит большинству ответов здесь. Даже если он не содержит переменных-членов (т. Е. Никакого состояния), статический класс все еще может быть плохой идеей, потому что он не может быть издеваемым или расширенным (подклассифицированным), поэтому он побеждает некоторые из принципов OO

Согласно жесткой интерпретации объектно-ориентированного дизайна, следует избегать использования служебного класса.

Проблема в том, что если вы будете следовать жесткой интерпретации, вам нужно будет заставить свой класс на какой-то объект сортировки, чтобы выполнить много вещей.

Даже дизайнеры Java делают классы полезности (java.lang.Math приходит на ум)

Ваши варианты:

double distance = Math.sqrt(x*x + y*y);  //using static utility class

vs:

RootCalculator mySquareRooter = new SquareRootCalculator();
mySquareRooter.setValueToRoot(x*x + y*y);
double distance;
try{
   distance = mySquareRooter.getRoot();
}
catch InvalidParameterException ......yadda yadda yadda.      

Даже если мы должны избегать verbose, мы все равно можем:

Mathemetician myMathD00d = new Mathemetician()
double distance = myMathD00d.sqrt(...);

в этом случае, .sqrt () по-прежнему статично, так что же было бы в создании объекта в первую очередь?

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

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

Класс Math является ярким примером.

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

Пока вы об этом подумали, я не вижу проблем с вашим решением.

Звучит разумно.

Примечание. У классов, которые делают это часто, есть частный конструктор no-arg, чтобы компилятор выдавал ошибку, если программист пытается создать экземпляр статического класса.

Статические методы меня не волнуют (кроме тестирования).

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

Класс Collections в Java SDK имеет только статические члены.

Итак, вы идете, если у вас есть правильное обоснование - это не плохой дизайн

Как правило, это классы полезности, и в этом нет ничего плохого. Известные примеры включают o.a.c.l.StringUtils , o.a.c.d.DbUtils , o.s.w.b.ServletRequestUtils и т. Д.

Просто не увлекайтесь этим. Обратите внимание, что класс java.lang.Math относится только к математическим функциям. У вас может также быть класс StringUtilities, который содержит, например, обычные функции обработки строк, которые не входят в стандартный API. Но если ваш класс называется Утилиты, например, это намек на то, что вы можете разделить его.

Обратите внимание, что Java специально ввела статический импорт: ( http://en.wikipedia.org/wiki/Static_import )

Статический импорт - это функция введенный на языке программирования Java, что члены (поля и методы), определенные в классе, как public static, которые будут использоваться в Java-коде без указания класса, в котором определено поле. Эта функция была введена в язык версии 5.0.

Функция предоставляет механизм типов для включения констант в код без необходимости ссылаться на класс, который первоначально определял поле. Это также помогает отказаться от практики создания постоянного интерфейса: интерфейса, который определяет константы, а затем записывает класс, реализующий этот интерфейс, который считается ненадлежащим использованием интерфейсов [1].

Механизм может быть используется для ссылки на отдельные члены класса:

 import static java.lang.Math.PI;
 import static java.lang.Math.pow;

или все статические члены класса:

 import static java.lang.Math.*;

Методы полезности часто помещаются в классы только с статическими методами (например, StringUtils.) Глобальные константы также помещаются в их собственный класс, так что они могут быть импортированы остальными атрибутами кода (public final static.)

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

Если в static member variables вы не имели в виду глобальные константы, вы можете захотеть поместить методы, обращающиеся к этим переменным, в свой собственный класс. В этом случае вы могли бы объяснить, что эти переменные делают в вашем коде?

Меня не интересовало бы класс утилиты, содержащий статические методы.

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

Это совершенно разумно. На самом деле, в C # вы можете определить класс с ключевым словом static специально для этой цели.