Чи коли-небудь корисно використовувати назву шаблону дизайну в класах реалізації? [зачинено]

Нещодавно я натрапив на помірно великому пітон кодовий з великою кількістю 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 { ... }