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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Моего 2 цента :)

Answer 5

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

Answer 6

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

Answer 7

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

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

Основная изношенном:

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

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

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

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

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

Удачи вам!

Answer 8

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

Answer 9

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

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