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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Редактировать:

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

Answer 3

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

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

Answer 4

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

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

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

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

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