Слишком много «суффиксов шаблонов» - дизайн запаха?

Question

Я только что создал себе класс под названием «InstructionBuilderFactoryMapFactory». Это 4 "суффикса шаблонов" на одном классе. Он сразу напомнил мне об этом:

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

Является ли это дизайн запах? Должен ли я налагать лимит на это число?

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

Все классы, кажется мне надо. У меня есть (фиксированная) карта от строк до фабрик - что-то я делаю все время. Список длиннее, и я хочу переместить его из конструктора класса, который использует сборщиков (созданных фабриками, которые получены с карты ...) И, как обычно, я избегаю синглтонов.

Answer 1

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

Я не понимаю, почему вы хотели назвать класс «InstructionBuilderFactoryMapFactory»? Существуют ли другие заводы - что-то, что не создает InstructionBuilderFactoryMap? Или есть ли какие-либо другие типы инструкций, которые должны быть сопоставлены?

Это те вопросы, о которых вы должны думать, когда начинаете создавать подобные классы. Можно просто объединить все эти заводские фабрики только с одним, а затем предоставить отдельные методы для создания заводов. Также можно просто поставить заводскую фабрику в другую упаковку и дать им более сжатое название. Подумайте об альтернативных способах этого.

Answer 2

Многие образцы в названии класса, безусловно, являются запахом, но запах не является определенным индикатором. Это сигнал «остановиться на минуту и ​​переосмыслить дизайн». Много раз, когда вы сидите сложа руки и думаете, что более ясное решение становится очевидным. Иногда из-за ограничений (техническая/временная/мужская мощность/и т. Д.) Означает, что запах следует игнорировать на данный момент.

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

Answer 3

Хороший совет: ваш открытый API (и его имя) должен раскрывать намерение, а не реализацию. Я (как клиент) не заботясь о том, был ли вы реализован шаблон строителя или заводской шаблон.

Не только имя класса выглядит плохо, но и ничего не говорит о том, что он делает. Это имя основано на его реализации и внутренней структуре.

Я редко использую имя шаблона в классе, за исключением (иногда) заводов.

Edit:

Нашли интересную article об именовании на Coding Horror, пожалуйста, проверьте это!

Answer 4

Я думал об одном и том же. В моем случае обилие фабрик вызвано «сборкой для проверки». Например, у меня есть конструктор, как это:

ParserBuilderFactoryImpl(ParserFactory psF) { 
... 
} 

Здесь у меня есть синтаксический анализатор - конечный класс, который мне нужен. Парсер построен путем вызова методов в построителе. Строители (новые для каждого парсера, которые должны быть построены) получены от завода-изготовителя.

Теперь, что такое h..l - ParserFactory? Ах, я рад, что ты спросил! Чтобы проверить реализацию построителя парсера, мне нужно вызвать его метод, а затем посмотреть, какой создатель парсера создан. Единственный способ сделать это без взлома инкапсуляции конкретного класса парсера, который создает строитель, - это поставить точку перехвата непосредственно перед созданием парсера, чтобы увидеть, что входит в его конструктор. Следовательно, ParserFactory. Это просто способ наблюдать в единичном тесте, что передается конструктору парсера.

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