Nommer les classes - Comment éviter de tout appeler "<WhatEver>Manager" ?

Question

Il y a longtemps, j'ai lu un article (un article de blog, je crois) qui m'a mis sur la "bonne" voie pour nommer les objets : Soyez très très scrupuleux pour nommer les objets dans votre programme.

Par exemple, si mon application gère des utilisateurs, des sociétés et des adresses (comme une application commerciale typique), j'aurais un fichier de type User , a Company et un Address classe de domaine - et probablement quelque part une UserManager , a CompanyManager et un AddressManager apparaîtrait pour gérer ces choses.

Alors pouvez-vous dire ce que ces UserManager , CompanyManager y AddressManager faire ? Non, car Manager est un terme très très générique qui correspond à tout ce que vous pouvez faire avec les objets de votre domaine.

L'article que j'ai lu recommandait d'utiliser des noms très spécifiques. S'il s'agissait d'une application C++ et que le UserManager Le travail de l'utilisateur est d'allouer et de libérer les utilisateurs du tas, il ne gère pas les utilisateurs mais surveille leur naissance et leur mort. Hmm, peut-être que nous pourrions appeler cela un UserShepherd .

Ou peut-être que le UserManager Le travail de TU est d'examiner les données de chaque objet utilisateur et de signer les données de manière cryptographique. Nous aurions alors un UserRecordsClerk .

Maintenant que cette idée est restée dans ma tête, j'essaie de l'appliquer. Et je trouve cette idée simple étonnamment difficile.

Je peux décrire ce que font les classes et (tant que je ne me laisse pas aller à un codage rapide et sale) les classes que j'écris font exactement ce que je veux. un chose. Ce qui me manque pour passer de cette description aux noms est une sorte de catalogue de noms, un vocabulaire qui fait correspondre les concepts aux noms.

En fin de compte, j'aimerais avoir quelque chose comme un catalogue de modèles dans mon esprit (fréquemment, les modèles de conception fournissent facilement les noms d'objets, par exemple une usine )

• Factory - Crée d'autres objets (dénomination tirée du design pattern)

• Berger - Un berger gère la durée de vie des objets, leur création et leur fermeture.

• Synchronizer - Copie les données entre deux ou plusieurs objets (ou hiérarchies d'objets).

• Nanny - Aide les objets à atteindre un état "utilisable" après leur création, par exemple en les connectant à d'autres objets.

• etc. etc.

Alors, comment gérez-vous ce problème ? Avez-vous un vocabulaire fixe, inventez-vous de nouveaux noms à la volée ou considérez-vous que nommer les choses n'est pas si important ou incorrect ?

P.S. : Je suis également intéressé par les liens vers les articles et les blogs qui traitent de cette question. Pour commencer, voici l'article original qui m'a fait réfléchir à la question : Nommer les classes Java sans "gestionnaire".

---

Mise à jour : résumé des réponses

Voici un petit résumé de ce que j'ai appris entre-temps de cette question.

• Essayez de ne pas créer de nouvelles métaphores (Nanny)
• Jetez un coup d'œil à ce que font les autres cadres

Autres articles/livres sur ce sujet :

• Quels sont les noms que vous vous surprenez à ajouter régulièrement à vos cours ?
• Quelle est la meilleure approche pour nommer les classes ?
• Livre : Design Patterns : Elements of Reusable Object-Oriented Software (couverture rigide)
• Livre : Patrons d'architecture d'application d'entreprise (Hardcover)
• Livre : Implementation Patterns (Broché)

Et une liste actuelle de préfixes/suffixes de noms que j'ai recueillis (subjectivement !) à partir des réponses :

• Coordinateur
• Constructeur
• Écrivain
• Lecteur
• Manipulateur
• Container
• Protocole
• Cible
• Convertisseur
• Contrôleur
• Voir
• Usine
• Entité
• Seau

Et un bon conseil pour la route :

Ne tombez pas dans la paralysie des noms. Oui, les noms sont très importants, mais ils ne le sont pas assez pour qu'on y perde un temps fou. Si vous ne parvenez pas à trouver un bon nom en 10 minutes, passez à autre chose.

Answer 1

J'ai demandé à un question similaire mais, dans la mesure du possible, j'essaie de copier les noms qui se trouvent déjà dans la base de données. .NET et je cherche des idées dans le Java y Android cadres.

Il semble Helper , Manager et Util sont les noms inévitables que vous attachez aux classes de coordination qui ne contiennent aucun état et sont généralement procédurales et statiques. Une alternative est Coordinator .

Vous pourriez vous lancer dans une prose particulièrement violette avec les noms et choisir des choses comme Minder , Overseer , Supervisor , Administrator et Master mais, comme je l'ai dit, je préfère conserver les noms des cadres auxquels vous êtes habitués.

---

D'autres suffixes courants (si c'est le terme correct) se trouvent également dans la langue de l'UE. .NET cadre sont :

• Builder
• Writer
• Reader
• Handler
• Container

Answer 2

Vous pouvez jeter un coup d'œil à source-code-wordle.de J'y ai analysé les suffixes les plus fréquemment utilisés dans les noms de classes du framework .NET et de quelques autres bibliothèques.

Les 20 premiers sont :

• attribut
• type
• aide
• collection
• convertisseur
• manipulateur
• info
• fournisseur
• exception
• service
• élément
• manager
• nœud
• option
• usine
• contexte
• article
• designer
• base
• éditeur

Answer 3

Je suis tout à fait favorable aux bons noms, et j'écris souvent sur l'importance d'apporter un grand soin au choix des noms des choses. Pour cette même raison, je me méfie des métaphores lorsque je nomme des choses. Dans la question originale, "factory" et "synchronizer" semblent être de bons noms pour ce qu'ils semblent signifier. Cependant, "berger" et "nounou" ne le sont pas, parce qu'ils sont basés sur métaphores . Une classe dans votre code ne peut pas être littéralement une nounou ; vous l'appelez une nounou parce qu'elle s'occupe d'autres choses comme une vraie nounou s'occupe de bébés ou d'enfants. C'est acceptable dans un discours informel, mais pas (à mon avis) pour nommer des classes dans un code qui devra être maintenu par qui sait qui, qui sait quand.

Pourquoi ? Parce que les métaphores dépendent de la culture et souvent aussi de l'individu. Pour vous, nommer une classe "nounou" peut être très clair, mais peut-être que ce n'est pas aussi clair pour quelqu'un d'autre. Nous ne devrions pas nous fier à cela, à moins que vous n'écriviez un code destiné uniquement à un usage personnel.

Dans tous les cas, la convention peut faire ou défaire une métaphore. L'utilisation de "factory" en soi est basée sur une métaphore, mais une métaphore qui existe depuis un certain temps et qui est actuellement assez bien connue dans le monde de la programmation, donc je dirais qu'on peut l'utiliser en toute sécurité. En revanche, "nounou" et "berger" sont inacceptables.

Answer 4

Ça ressemble à une pente glissante vers quelque chose qui serait posté sur thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages", etc.

Je suppose qu'il est vrai qu'une classe Manager monolithique n'est pas une bonne conception, mais utiliser 'Manager' n'est pas mauvais. Au lieu de UserManager, nous pourrions le décomposer en UserAccountManager, UserProfileManager, UserSecurityManager, etc.

Le terme "gestionnaire" est un bon mot car il montre clairement qu'une classe ne représente pas une "chose" du monde réel. AccountsClerk" - comment puis-je savoir s'il s'agit d'une classe qui gère les données des utilisateurs ou qui représente quelqu'un qui est comptable dans son travail ?

Answer 5

Puisque vous vous intéressez aux articles dans ce domaine, vous pourriez être intéressé par l'article d'opinion de Steve Yegge intitulé "L'exécution au royaume des noms" :

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html