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

Question

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

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

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

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

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

Answer 1

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

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

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

Edit:

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

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

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

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