Czy warto używać nazwy wzorca projektowego w klasach wykonawczych? [Zamknięte]

Ostatnio natknąłem się na umiarkowanie dużej kodzie Pythona z partii MyClassAbstractFactory, MyClassManager, MyClassProxy, MyClassAdapteritd. Klas.

Podczas gdy z jednej strony te nazwiska skłoniły mnie do zbadania i poznania odpowiednich wzorców, nie były zbyt opisowe dla tego, co robi klasa .

Ponadto, wydaje się, że mieszczą się w zakazanej listy słów w programowaniu: variable, process_available_information, data, amount, compute: zbyt szerokie nazwy, które nie mówią nam nic na temat funkcji , gdy stosowane przez nich samych .

Czy powinno być, CommunicationManagerczy raczej PortListener? A może w ogóle nie rozumiem problemu ...?

• AbstractFactoryjest rzeczywiście kiepskim wyborem dla imienia. Nie ma sposobu, aby dowiedzieć się, co jest tworzone przez tę fabrykę , a kiedy będziesz szukać encji, która tworzy Animals, nigdy nie znajdziesz odpowiedniej fabryki według nazwy.

• AnimalAbstractFactorynie jest mądrym wyborem, ponieważ w większości języków byłoby zbędne ze abstractsłowem kluczowym w podpisie.

  Biorąc to pod uwagę, istnieje kilka dobrych powodów, podkreślonych w komentarzach, które faktycznie należy uwzględnić Abstractw nazwie: nie tylko istnieje kilka kontekstów, w których nie masz pełnego podpisu, ale tylko nazwa, ale także utrzymywanie AnimalFactoryinterfejsu może być mądrym wyborem (chyba że niestety konwencją języka / frameworka jest prefiks interfejsu I).

• AnimalCreationUtilitybyłby również zły wybór: jeśli jest to fabryka , ułatw rzeczy ludziom, którzy będą czytać kod i nazywają to fabryką .

• abstract AnimalFactoryjest ok Nie ma nadmiarowości i jest jasne, że jest to abstrakcyjna fabryka, która deleguje tworzenie zwierząt swoim dzieciom.

Tak więc, w tym nazwa wzorca projektowego jest dobrym pomysłem, ale powinna być tylko częścią nazwy i nie powinna być zbędna z innymi częściami podpisu.

Zależy od konkretnego przykładu. Wzorzec Konstruktora jest prawie zawsze najlepiej obsługiwany, nazywając Konstruktora klasy *, podczas gdy Singleton zwykle nie musi być tak nazwany.

Jeśli nie umieścisz nazwy wzorca w nazwie klasy, a może nawet jeśli tak zrobisz, zazwyczaj powinieneś umieścić w klasie komentarz wyjaśniający, że implementuje on określony wzorzec.

Głównym celem używania nazw wzorców w klasach jest ułatwienie zrozumienia, co robi klasa. Jeśli nazwiesz klasę AnimalFactory, oczywiste jest, że klasa tworzy instancje zwierząt. Jeśli nazwa twojej klasy zawiera nazwę wzorca i nie opisuje tego, co robi, wybrałeś zły wzorzec lub niewłaściwie go zaimplementowałeś.

Myślę, że to może działać naprawdę dobrze. Na przykład:

// 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 { ... }