Минусы статические классы в Java?

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

3 ответов


в них нет ничего плохого, в правильном контексте. Если у вас есть автономные методы без состояния (например, найденные в java.lang.Math), то статический класс является идеальным местом для них. Единственная причина, по которой они вообще находятся в классе, заключается в том, что Java не имеет понятия о самостоятельных методах.


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

например, используя System.currentTimeMillis() легко получить текущее время. Но когда вам нужно протестировать класс, который использует текущее время для выполнения некоторой работы, невозможно издеваться над методом, чтобы заставить его вернуть определенный момент времени. Использование объекта, реализующего Clock интерфейс и введенный в объект для тестирования, значительно упрощает его: вы можете создать макет реализации часов, возвращающий определенную дату, когда вас попросят получить текущее время.


Я говорил об этом некоторое время назад в сообщении, которое вы можете найти здесь.

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

  1. Mockability, как и другие плакаты указал.
  2. несколько версий статического класса могут быть загружены в приложение в зависимости от иерархии загрузчика классов и пути к классу, настроенного для всей иерархии загрузчиков классов. (Третий элемент также, если загрузчик классов настроен как parent first или child first) делает тестирование и отладку этого кошмара.
  3. статический метод не может наследоваться. Следовательно, нарушает OCP (открытый закрытый принцип) т. е. статический метод не является расширяемым. Посмотрите на Log4J для типичных проблем со статическими методами.
  4. статический метод не поддается применению ни Принцип Разделения Интерфейса или стратегия узор. Невозможно иметь альтернативный реализации аналогичного алгоритма в зависимости от индивидуальных случаев использования без обращения к обильному количеству рукописного кода, щедро распыленного с "условиями if".

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