У меня есть класс, который состоит только из статических переменных-членов и статических методов. По сути, он служит универсальным классом утилиты.
Является ли плохая практика для класса содержать только статические переменные-члены и статические методы?
Нет, я так не думаю. Хуже практика состоит в том, чтобы класс был заполнен методами экземпляра, которые фактически не зависят от конкретного экземпляра. Создание их статических данных указывает пользователю точно, как они предназначены для использования. Кроме того, вы избегаете ненужных экземпляров таким образом.
EDIT: В качестве задумчивости, в общем, я считаю, что приятно избегать использования языковых функций "только потому, что" или потому, что вы считаете, что это "способ Java для этого". Я помню свою первую работу, где у меня был класс, полный статических методов утилиты, и один из старших программистов сказал мне, что я не полностью использовал возможности OO Java, сделав все мои методы "глобальными". Через 6 месяцев ее не было в команде.
Пока класс не имеет внутреннего состояния и, по сути, это то, что известно как листовой класс (классы полезности попадают в эту категорию), другими словами он не зависит от других классов. Это нормально.
Класс Math является ярким примером.
Звучит разумно.
Примечание. Классы, которые делают это, часто имеют частный конструктор no-arg, чтобы компилятор выдавал ошибку, если программист пытается создать экземпляр статического класса.
Статические методы меня не волнуют (кроме тестирования).
В общем, статические члены являются предметом озабоченности. Например, что, если ваше приложение кластеризовано? Как насчет времени запуска - какая инициализация происходит? Чтобы рассмотреть эти проблемы и многое другое, ознакомьтесь с этой статьей Гиладом Брашей.
Это совершенно разумно. Фактически, в С# вы можете определить класс с ключевым словом static специально для этой цели.
Просто не увлекайтесь этим. Обратите внимание, что класс java.lang.Math относится только к математическим функциям. У вас может также быть класс StringUtilities, который содержит, например, обычные функции обработки строк, которые не входят в стандартный API. Но если ваш класс называется Утилиты, например, это подсказка, что вы можете разделить ее.
Обратите внимание, что 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.*;
В то время как я согласен с тем, что это звучит как разумное решение (как уже отмечали другие), одна вещь, которую вы можете рассмотреть, с точки зрения дизайна, почему у вас есть класс только для целей "полезности", Являются ли эти функционалы действительно общими для всей системы или они действительно связаны с определенным классом объектов в вашей архитектуре.
Пока вы об этом подумали, я не вижу проблем с вашим решением.
Класс Collections в Java SDK содержит только статические члены.
Итак, вы идете, пока у вас есть правильное оправдание - это не плохой дизайн
Утилиты часто помещаются в классы только с статическими методами (например, StringUtils.) Глобальные константы также помещаются в их собственный класс, так что они могут быть импортированы остальной частью кода (public final static attributes.)
Оба использования довольно распространены и имеют встроенные конструкторы по умолчанию, чтобы предотвратить их создание. Объявление окончательного класса предотвращает ошибку при попытке переопределить статические методы.
Если в static member variables вы не имели в виду глобальные константы, вы можете захотеть поместить методы, получающие эти переменные, в свой собственный класс. В этом случае вы могли бы объяснить, что эти переменные делают в вашем коде?
Как правило, это классы утилиты, и в этом нет ничего плохого. Известные примеры включают o.a.c.l.StringUtils, o.a.c.d.DbUtils, o.s.w.b.ServletRequestUtils и т.д.
В соответствии с жесткой интерпретацией объектно-ориентированного дизайна полезный класс - это то, чего следует избегать.
Проблема в том, что если вы будете следовать жесткой интерпретации, вам нужно будет заставить свой класс на какой-то объект сортировки, чтобы выполнить много вещей.
Даже дизайнеры 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() по-прежнему является статичным, так что будет в первую очередь создавать объект?
Ответ: создать классы утилит, когда другим вариантом будет создание какого-то искусственного класса "Рабочий", который не имеет или мало использует переменные экземпляра.
Эта ссылка http://java.dzone.com/articles/why-static-bad-and-how-avoid, похоже, противоречит большинству ответов здесь. Даже если он не содержит переменных-членов (т.е. Никакого состояния), статический класс все еще может быть плохой идеей, потому что он не может быть издеваемым или расширенным (подклассифицированным), поэтому он побеждает некоторые из принципов OO
Меня не интересовал бы класс утилиты, содержащий статические методы.
Однако статические члены являются по существу глобальными данными и их следует избегать. Они могут быть приемлемыми, если они используются для кеширования результатов статических методов и т.д., Но если они используются как "реальные" данные, которые могут привести к возникновению всех проблем, таких как скрытые зависимости и трудности при настройке тестов.