Est-ce jamais une bonne idée d'utiliser le nom du modèle de conception dans les classes d'implémentation? [fermé]

Récemment , je suis tombé sur une base de code python modérément large avec beaucoup de MyClassAbstractFactory, MyClassManager, MyClassProxy, MyClassAdapteretc. classes.

Alors que d'une part ces noms m'a fait faire des recherches et d' apprendre les modèles correspondants, ils ne sont pas très descriptif de ce que la classe ne .

, Ils semblent aussi tomber dans la liste des mots interdits dans la programmation: variable, process_available_information, data, amount, compute: noms trop larges, qui ne nous disent rien sur la fonction lorsqu'ils sont utilisés par eux - mêmes .

Alors devrait-il y en avoir CommunicationManagerou plutôt PortListener? Ou peut-être que je ne comprends pas du tout le problème ...?

• AbstractFactoryest en effet un mauvais choix pour un nom. Il n'y a aucun moyen de savoir ce qui est créé par cette usine , et lorsque vous recherchez une entité qui crée Animals, vous ne trouverez jamais l'usine correspondante par son nom.

• AnimalAbstractFactoryn'est pas non plus un choix judicieux, car dans la plupart des langues, il serait redondant avec le abstractmot - clé dans la signature.

  Cela étant dit, il y a plusieurs bonnes raisons, soulignées par les commentaires, d'inclure réellement Abstractdans le nom: non seulement il y a plusieurs contextes où vous n'avez pas la signature complète, mais juste le nom, mais aussi, en gardant AnimalFactoryune interface peut être un choix judicieux (sauf si, malheureusement, la convention du langage / framework est de préfixer les interfaces avec I).

• AnimalCreationUtilityserait également un mauvais choix: s'il s'agit d'une usine , rendez les choses plus faciles pour les personnes qui liront le code et l' appelleront une usine .

• abstract AnimalFactoryest ok. Il ne dispose pas de redondance, et il est clair que c'est une abstraite usine qui délègue la création d'animaux à ses enfants.

Alors oui, inclure le nom du motif de conception est une bonne idée, mais cela ne devrait être qu'une partie du nom et ne devrait pas être redondant avec les autres parties de la signature.

Dépend de l'exemple spécifique. Le modèle Builder est presque toujours mieux servi en nommant votre classe * Builder, alors qu'un Singleton n'a généralement pas besoin d'être nommé comme tel.

Si vous ne mettez pas le nom du modèle dans le nom de votre classe, et peut-être même si vous le faites, vous devriez généralement mettre un commentaire dans la classe qui explique qu'il implémente un modèle spécifique.

L'intérêt de l'utilisation des noms de modèle dans les classes est de faciliter la compréhension de ce que fait la classe. Si vous nommez la classe AnimalFactory, il est évident que la classe crée des instances Animal. Si le nom de votre classe comprend le nom d'un modèle et qu'il ne décrit pas ce qu'il fait, vous avez soit choisi un mauvais modèle, soit l'implémenté incorrectement.

Je pense que cela peut très bien fonctionner. Par exemple:

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