¿Alguna vez es una buena idea usar el nombre del patrón de diseño en las clases de implementación? [cerrado]

Recientemente me encontré con una gran base de código Python moderadamente con una gran cantidad de MyClassAbstractFactory, MyClassManager, MyClassProxy, MyClassAdapteretc clases.

Mientras que, por un lado esos nombres me señaló a investigar y aprender los patrones correspondientes, que no eran muy descriptivo de lo que la clase lo hace .

Además, parecen caer dentro de la lista prohibida de palabras en la programación: variable, process_available_information, data, amount, compute: nombres excesivamente amplias, que no nos dicen nada acerca de la función cuando se utiliza por sí mismos .

Entonces, ¿debería haberlo CommunicationManagero más bien PortListener? ¿O tal vez no entiendo el problema en absoluto ...?

• AbstractFactoryde hecho es una mala elección para un nombre. No hay forma de saber qué crea esta fábrica , y cuando busque una entidad que cree Animals, nunca encontrará la fábrica correspondiente por su nombre.

• AnimalAbstractFactorytampoco es una elección acertada, ya que en la mayoría de los idiomas, sería redundante con la abstractpalabra clave en la firma.

  Dicho esto, hay varias buenas razones, destacadas por los comentarios, para incluir realmente Abstracten el nombre: no solo hay varios contextos en los que no tiene la firma completa, sino solo el nombre, sino también, manteniendo AnimalFactoryuna interfaz puede ser una buena elección (a menos que, desafortunadamente, la convención del lenguaje / marco sea prefijar las interfaces con I).

• AnimalCreationUtilityTambién sería una mala elección: si se trata de una fábrica , facilitar las cosas para las personas que leerán el código y llamarlo fábrica .

• abstract AnimalFactoryesta bien No tiene redundancia, y está claro que es una fábrica abstracta que delega la creación de animales a sus hijos.

Entonces sí, incluir el nombre del patrón de diseño es una buena idea, pero debe ser solo una parte del nombre y no debe ser redundante con las otras partes de la firma.

Depende del ejemplo específico. El patrón de Constructor casi siempre se sirve mejor nombrando a su clase * Generador, mientras que un Singleton generalmente no necesita ser nombrado como tal.

Si no pone el nombre del patrón en el nombre de su clase, y tal vez incluso si lo hace, generalmente debería poner un comentario en la clase que explique que implementa un patrón específico.

El objetivo de usar nombres de patrones en las clases es facilitar la comprensión de lo que hace la clase. Si nombra la clase AnimalFactory, es obvio que la clase crea instancias de Animal. Si el nombre de su clase incluye el nombre de un patrón y no describe lo que hace, ha elegido un patrón incorrecto o lo ha implementado incorrectamente.

Creo que puede funcionar muy bien. Por ejemplo:

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