Является ли когда-нибудь хорошей идеей использовать имя шаблона проектирования в реализующих классах? [закрыто]

Недавно я наткнулся на умеренно большом питон кодовый с большим количеством MyClassAbstractFactory, MyClassManager, MyClassProxy, и MyClassAdapterт.д. классов.

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

Кроме того , они , кажется, попадают в список запрещенных слов в программировании: variable, process_available_information, data, amount, compute: чрезмерно широкие имена, которые не говорят нам ничего о функции , когда используются сами по себе .

Так должно быть CommunicationManagerили скорее PortListener? А может я вообще не понимаю проблемы ...?

• AbstractFactoryдействительно плохой выбор для имени. Нет никакого способа узнать, что создано этой фабрикой , и когда вы будете искать сущность, которая создает Animals, вы никогда не найдете соответствующую фабрику по имени.

• AnimalAbstractFactoryэто не мудрый выбор, так как в большинстве языков он будет избыточным с abstractключевым словом в подписи.

  При этом, есть несколько веских причин, выделенных комментариями, на самом деле включить Abstractв имя: не только несколько контекстов, где у вас нет полной подписи, но только имя, но также и сохранение AnimalFactoryинтерфейса может быть разумным выбором (если, к сожалению, соглашение языка / фреймворка не заключается в добавлении префиксов к интерфейсам I).

• AnimalCreationUtilityЭто также был бы плохой выбор: если это фабрика , сделайте проще для людей, которые будут читать код, и назовите это фабрикой .

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

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

Зависит от конкретного примера. Образец Builder почти всегда лучше всего именовать классом * Builder, в то время как Singleton обычно не нужно называть таковым.

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

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

Я думаю, что это может работать очень хорошо. Например:

// Command for retrying card entry with CVN.
public class RetryCardEntryWithCVNCommand { ... }

// Query for getting expired accounts
public class GetExpiredAccountsQuery { ... }

// Decorator for logging exception. Implies that it's an additional 
//mechanism for logging exceptions.
public class LogExceptionToDbDecorator { ... }

// Factory for creating account filters
public class AccountFilterFactory { ... }