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

28

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

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

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

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

Vorac
источник
если вы знакомы с тем, что делает шаблон, тогда имя шаблона является достойным описанием, однако просто имя шаблона является плохой идеей, лучше иметь MyClassFactory, FooAdapter и т. д.
freak
Отредактировал вопрос, чтобы указать, что классы назывались не просто «AbstractFactory», но там также были некоторые описательные слова.
Vorac
1
... они серьезно называли это Fctoryвместо Factory, или это просто опечатка?
Изката,
@Izkata, лол, мой плохой. Однако были Адаптер и Адаптер!
Vorac

Ответы:

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

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

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

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

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

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

Арсений Мурзенко
источник
2
Почему это лучше, чем писать комментарии на видном месте? »В этом модуле мы реализуем MVC. Причины: ... Модели: ... Представления: ... Контроллеры: ... Структура карты: ... API :. .. "
Vorac
37
@Vorac: Четкое имя всегда лучше, чем полагаться на комментарии.
Арсений Мурзенко
2
@Vorac рано или поздно кто-то добавит новый класс, не обновляя этот заметный комментарий (или даже не зная о его существовании). Хотя гораздо сложнее не учитывать соглашение об именах, последовательно используемое во всем приложении.
Конрад Моравский
2
Пока вы просматриваете свое проектное решение, откроете ли вы каждый файл класса, чтобы найти, что он делает? Вот почему всегда лучше иметь описательные имена классов / файлов.
матрица
2
Я хотел бы любезно не согласиться со вторым пунктом: я думаю, что AnimalAbstractFactory - хороший выбор, потому что, хотя он является избыточным в объявлении класса, он был бы очень полезен в объявлении дочернего класса: LionFactory расширяет AnimalAbstractFactory, который, я думаю, это хорошая информация.
Игорь
11

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

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

MikeFHay
источник
3
Согласованность здесь крайне важна, потому что, когда вызываются только некоторые фабрики ...Factory, становится разумным понять, что класс - это фабрика, если его наименование нарушает это соглашение.
Конрад Моравский
10

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

Pavels
источник
1

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

// 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 { ... }
CodeART
источник
1
как это отвечает на заданный вопрос? Насколько я понимаю, ваши «примеры» показывают только бесполезное дублирование имен классов и комментариев к коду
gnat
Комментарии служат для обоснования цели каждого класса в случае, если имя класса не является очевидным для некоторых. Глядя на них, я сразу узнаю, что у меня есть команда, которая делает что-то, запрос, который возвращает данные, декоратор, который добавляет дополнительное поведение к существующему механизму регистрации исключений, и фабрика, которая создает фильтры учетных записей. По моему мнению, чем более информативны вы с именами классов, тем легче другим будет читать ваш код. Если вы используете шаблон проектирования, то, скажем так - в конце дня вся цель создания шаблонов проектирования состоит в том, чтобы облегчить другим чтение вашего кода
CodeART