Минусы статических служебных классов в Java?

Question

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

1. Подвижность, как указывалось в других постерах.
2. Несколько версий статического класса могут быть загружены в приложение в зависимости от иерархии загрузчиков классов и пути к классам, настроенных для всей иерархии загрузчиков классов.(Третий элемент также используется, если загрузчик классов настроен как родительский или дочерний сначала). Это делает кошмар тестированием и отладкой.
3. Статический метод не может быть унаследован от.Следовательно, нарушает OCP (открытый закрытый принцип) , то есть статический метод не является расширяемым.Посмотрите на Log4J типичные проблемы со статическими методами.
4. Статический метод не подходит для применения Принципа разделения интерфейсов или шаблона Стратегия .Невозможно иметь альтернативные реализации аналогичного алгоритма в зависимости от индивидуальных случаев использования без обращения к обильному количеству рукописного кода, обильно опрыскиваемого «условиями условия».

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