Вопросы проектирования для класса, полного статических методов

Question

Будучи разработчиком Swing столько лет, сколько можно быть разработчиком Swing, я определил множество шаблонов, которые я использую при разметке компонентов. Например, я часто создаю компоненты, связанные с JLabel. Я обычно пишу:

JPanel panel = new JPanel(new BorderLayout());
panel.add(label, BorderLayout.NORTH);
panel.add(list, BorderLayout.CENTER);

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

JPanel panel = LayoutPatterns.createNorthLabeledPanel(label, list);

... что значительно снижает мою нагрузку при наборе текста.

Итак, теперь у меня есть класс, заполненный примерно 20 статическими методами. У класса нет состояния - весь контекст передается через параметры метода.

Кроме Java-класса Math, я не видел классов, которые полностью состоят из статических методов и не имеют состояния.

С одной стороны, это не правильно. С другой стороны, я не вижу в этом ничего плохого.

Это нормально для использования или что-то, что указывает на запах кода? Если этот шаблон был применен к другому домену, должен ли я беспокоиться о многопоточном использовании класса статики? Вы бы отказались, если бы увидели это в коде качества производства?

Answer 1

Я думаю, что единственная проблема здесь - это язык, который вынуждает вас изобрести класс, в котором -gasp- глобальные функции полностью уместны. : -)

Answer 2

Я думаю, что такие вещи обычно имеют неприятный запах кода. Тем не менее, я с вами, я не вижу ничего особенно плохого в этом деле.

Я думаю, вы отлично объяснили и обосновали свой дизайн.

Думая о возможной альтернативе, возможно, вы могли бы унаследовать JPanel и создать NorthLabelJPanel (или, может быть, даже лучше создать новый класс, содержащий JPanel). Однако я не уверен, стоит ли это усилий. Я думаю, что ваш код выглядел бы более сложным, даже если это может быть лучше "по книге".

Мои 2 цента:)

Answer 3

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

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

Answer 4

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

Я сам написал код, похожий на этот.

Answer 5

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

Answer 6

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

Answer 7

Я думаю, что если вы разрабатываете в объектно-ориентированной среде, у вас есть только два варианта:

1. Сделать все методы класса статичными.
2. Разработайте обычный класс и используйте шаблон синглтона.

Answer 8

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

В мире шаблонов проектирования я вижу шаблон Builder, применяемый к подобным случаям, который, по-видимому, и является тем, к чему стремится Java API.

Базовое краткое изложение:

1. Создание простого предмета, мало или совсем без украшения
2. Добавить объекты / атрибуты / и т. Д. чтобы это выглядело / делало что хочешь

ПРИМЕЧАНИЕ. Прелесть в том, что вы не знаете, как будет выглядеть конечный результат, пока не закончите, что дает вам полный диапазон гибкости.

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

Теперь, с учетом сказанного, я написал и использовал большую коллекцию того, что я называю «Службы», классы, которые не имеют состояния и имеют только статические методы (как вы описали), и они спасли меня от написания (и что еще более важно, дублирование) много моих основных процедур. Они могут оказаться очень полезными, если их использовать должным образом, но я склонен использовать их только для самых простых (и распространенных) подпрограмм, таких как форматирование текста, копирование массивов, преобразование массивов с плавающей точкой в ​​двойные массивы (в C ++) или что-либо еще, что вы ожидаете найти в стандартной библиотеке.

Это действительно зависит от того, насколько «статичны» ваши статические методы. Если вы не видите, что их нужно так часто обслуживать или обновлять, то, вероятно, вам не помешает привязать их к тому, что вы описали. Тем не менее, если в будущем есть какой-либо шанс на повторный факторинг, я думаю, что вы должны предпочесть оставить его как можно более гибким, что, к сожалению, означает каждый раз делать вызовы API вручную.

Удачи!

Answer 9

VB.NET и теперь C # даже имеют языковую поддержку для статических классов (VB называет их Модулями), так что вы можете проверить компилятором, что они действительно все статические.