Это плохая практика для класса иметь только статические поля и методы?

Question

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

Является ли плохой практикой для класса содержать только статические переменные-члены и статические методы?

Answer 1

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

РЕДАКТИРОВАТЬ: В общем, я думаю, что в целом неплохо избегать использования языковых функций «просто потому, что», или потому что вы думаете, что это «способ Java сделать это». Я вспоминаю свою первую работу, где у меня был класс, полный статических служебных методов, и один из старших программистов сказал мне, что я не полностью использую возможности ОО Java, сделав все свои методы «глобальными». Она не была в команде 6 месяцев спустя.

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

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

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

 import static java.lang.Math.*;

Answer 9

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

Answer 10

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

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

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

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

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

против

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

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

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

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

Ответ таков: создавайте служебные классы, когда вы можете создать искусственный класс "Worker", который не имеет или почти не используется для переменных экземпляра.