Naming Classes - Comment éviter de tout appeler un "<WhatEver> Manager"?

Question

Il y a longtemps, j'ai lu un article (je crois une entrée de blog) qui me mettait sur la bonne voie en matière de nommage des objets: soyez très très scrupuleux lorsque vous nommez des éléments dans votre programme.

Par exemple, si mon application traitait (en tant qu’application d’entreprise type) les utilisateurs, les entreprises et les adresses, j’aurais une classe User, Company et Address - et probablement quelque part une UserManager, un CompanyManager et un AddressManager apparaissent pour gérer ces éléments.

Alors pouvez-vous dire ce que ces UserManager, CompanyManager et AddressManager font? Non, car gestionnaire est un terme très générique qui convient à tout ce que vous pouvez faire avec vos objets de 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 travail de UserManager allouait et libérait les utilisateurs du tas, il ne gérerait pas les utilisateurs mais protégerait leur naissance et leur mort. Hmm, peut-être que nous pourrions appeler cela un UserShepherd.

Ou peut-être que le travail de UserManager consiste à examiner les données de chaque objet utilisateur et à les signer de manière cryptographique. Ensuite, nous aurions un UserRecordsClerk.

Maintenant que cette idée me vient à l'esprit, j'essaie de l'appliquer. Et trouvez cette idée simple incroyablement difficile.

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

En fin de compte, j'aimerais avoir quelque chose comme un catalogue de modèles dans mon esprit (les modèles de conception fournissent souvent facilement les noms d'objet, par exemple une fabrique ).

Factory - Crée d'autres objets (nom tiré du motif de conception)
Shepherd - Un berger gère la durée de vie des objets, leur création et leur arrêt
Synchroniseur - Copie des données entre deux objets ou plus (ou hiérarchies d'objets)
Nanny - Aide les objets à atteindre l'état "utilisable" après la création - par exemple, en les connectant à d'autres objets
etc.

Alors, comment gérez-vous ce problème? Avez-vous un vocabulaire fixe, inventez-vous de nouveaux noms à la volée ou envisagez-vous de nommer des choses sans importance ou mal?

P.S .: Je suis également intéressé par des liens vers des articles et des blogs traitant de la question. Pour commencer, voici l'article original qui m'a fait réfléchir: Nommer Java Classes sans 'Manager'

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

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

Essayez de ne pas créer de nouvelles métaphores (Nanny)
Regardez ce que font les autres cadres

Autres articles/livres sur ce sujet:

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

Coordinateur
Constructeur
Écrivain
Lecteur
Gestionnaire
Récipient
Protocole
Cible
Convertisseur
Manette
Vue
Usine
Entité
Seau

Et un bon pourboire pour la route:

Ne vous faites pas nommer paralysie. Oui, les noms sont très importants, mais ils ne le sont pas assez pour perdre beaucoup de temps. Si vous ne pouvez pas trouver un bon nom dans 10 minutes, passez à autre chose.

Chris S · Accepted Answer

J'ai posé un question similaire , mais dans la mesure du possible, j'essaie de copier les noms déjà présents dans le framework .NET et je cherche des idées dans les Java et Android. _ cadres.

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

Vous pouvez obtenir une prosey particulièrement violette avec les noms et opter pour des choses comme Minder, Overseer, Supervisor, Administrator et Master, mais comme je l'ai dit préférez le garder comme les noms de framework auxquels vous êtes habitué.

Quelques autres suffixes courants (si c'est le terme correct) que vous trouvez également dans le framework .NET sont:

Builder
Writer
Reader
Handler
Container

Markus Meyer · Answer

Vous pouvez jeter un oeil à source-code-wordle.de , j’y ai analysé les suffixes les plus fréquemment utilisés des noms de classe du framework .NET et de quelques autres bibliothèques.

Le top 20 sont:

attribut
type
assistant
collection
convertisseur
gestionnaire
info
fournisseur
exception
un service
élément
directeur
nœud
option
usine
le contexte
article
designer
base
éditeur

CesarGon · Answer

Je suis pour les bons noms et j'écris souvent sur l'importance de faire très attention lors du choix d'un nom. Pour cette même raison, je me méfie des métaphores lorsque je nomme des choses. Dans la question initiale, "usine" et "synchroniseur" ressemblent à de bons noms pour ce qu'ils semblent vouloir dire. Cependant, "berger" et "nounou" ne le sont pas, car ils sont basés sur métaphores. Une classe dans votre code ne peut pas être littéralement une nounou; vous appelez cela une nounou parce qu'elle s'occupe bien d'autres choses, tout comme une nounou réelle s'occupe de bébés ou d'enfants. Ce n'est pas grave dans un discours informel, mais pas (à mon avis) pour nommer des classes dans un code qui devra être maintenu par qui sait qui sait qui.

Pourquoi? Parce que les métaphores dépendent de la culture et dépendent souvent aussi des individus. 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 compter sur cela, à moins que vous n'écriviez du code destiné uniquement à un usage personnel.

Dans tous les cas, la convention peut faire ou défaire une métaphore. L'utilisation de "factory" elle-même est basée sur une métaphore, mais qui existe depuis assez longtemps et qui est actuellement assez bien connue dans le monde de la programmation, donc je dirais que son utilisation est sûre. Cependant, "nounou" et "berger" sont inacceptables.

herzmeister · Answer

Nous pourrions nous passer de toutes les classes xxxFactory, xxxManager ou xxxRepository si nous modélions correctement le monde réel:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"] .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"] .OfType<User>().CreateNew("John Doe");

;-)

Mr. Boy · Answer

Cela ressemble à une pente glissante vers quelque chose qui serait publié sur theailylywtf.com, "ManagerOfPeopleWhoHaveMortgages", etc.

Je suppose qu’il est vrai qu’une classe de gestionnaires monolithique n’est pas un bon concept mais l’utilisation de "Gestionnaire" n’est pas mauvaise. Au lieu de UserManager, nous pourrions le scinder en UserAccountManager, UserProfileManager, UserSecurityManager, etc.

"Manager" est un bon mot car il montre clairement qu'une classe ne représente pas une "chose" du monde réel. 'AccountsClerk' - comment suis-je censé dire s'il s'agit d'une classe qui gère les données utilisateur ou représente quelqu'un qui est un commis aux comptes pour son travail?

stusmith · Answer

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

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

Jeff Sternal · Answer

Quand je pense utiliser Manager ou Helper dans un nom de classe, je le considère comme une odeur de code qui signifie que je n'ai pas encore trouvé la bonne abstraction et/ou que je viole le - principe de responsabilité unique , le refactoring et le déploiement d'efforts de conception facilitent souvent le nommage.

Mais même les classes bien conçues ne se nomment pas (toujours), et vos choix dépendent en partie de la création de classes de modèle d'entreprise ou d'infrastructure technique.

Les classes de modèle métier peuvent être difficiles, car elles sont différentes pour chaque domaine. J'utilise beaucoup de termes, tels que Policy pour les classes de stratégie d'un domaine (par exemple, LateRentalPolicy), mais ceux-ci découlent généralement de la tentative de créer un " langage omniprésent) "que vous pouvez partager avec les utilisateurs professionnels en concevant et en nommant des classes afin de modéliser des idées, des objets, des actions et des événements du monde réel.

Les classes d'infrastructure technique sont un peu plus faciles, car elles décrivent des domaines que nous connaissons très bien. Je préfère incorporer les noms de modèle de conception dans les noms de classe, comme InsertUserCommand, CustomerRepository, ou SapAdapter. Je comprends la préoccupation liée à la communication de la mise en œuvre au lieu de l'intention, mais les modèles de conception associent ces deux aspects de la conception de classe - du moins lorsque vous traitez avec une infrastructure, où vous souhaitez que la conception de la mise en œuvre soit transparente même lorsque vous masquez les détails.

Brian Agnew · Answer

Être au fait de modèles définis par (disons) le livre GOF , et nommer des objets après eux me permet de nommer des classes, de les organiser et de communiquer des intentions. La plupart des gens comprendront cette nomenclature (ou du moins une partie importante de celle-ci).

Jasper van den Bosch · Answer

Si je ne peux pas proposer un nom plus concret pour ma classe que XyzManager, je pourrai me demander si c’est vraiment une fonctionnalité qui appartient à une classe, c’est-à-dire une "odeur de code" architecturale.

Droozle · Answer

Je pense que la chose la plus importante à garder à l'esprit est la suivante: le nom est-il suffisamment descriptif? Pouvez-vous dire en regardant le nom ce que la classe est censée faire? L'utilisation de mots tels que "Manager", "Service" ou "Handler" dans les noms de classe peut être considérée comme trop générique, mais étant donné que beaucoup de programmeurs les utilisent, cela permet également de comprendre le rôle de la classe.

J'ai moi-même beaucoup utilisé le motif de façade (du moins, je pense que c'est ainsi qu'il s'appelle). Je pourrais avoir une classe User qui décrit un seul utilisateur et une classe Users qui garde une trace de ma "collection d'utilisateurs". Je n'appelle pas la classe un UserManager parce que je n'aime pas les gestionnaires dans la vie réelle et je ne veux pas qu'on leur rappelle :) simplement d'utiliser le pluriel pour m'aider à comprendre ce que fait la classe.

AaronLS · Answer

J'ai trouvé que "Directives de conception de cadre: conventions, expressions et modèles pour les bibliothèques .NET réutilisables" contient beaucoup d'informations utiles sur la logique de nommage.

En ce qui concerne la recherche de mots plus spécifiques, j’utilise souvent un thésaurus et passe au premier plan avec des mots apparentés pour en trouver un bon. J'essaie toutefois de ne pas passer trop de temps dessus, au fur et à mesure que je progresse dans le développement, je trouve de meilleurs noms, ou je réalise parfois que SuchAndSuchManager devrait vraiment être divisé en plusieurs classes, puis le nom de cette classe déconseillée. devient un non-problème.

Lazarus · Answer

Je pense que la chose essentielle ici est d'être cohérent dans la sphère de visibilité de votre code, c'est-à-dire tant que tous ceux qui ont besoin de regarder/travailler sur votre code comprennent votre convention de dénomination, alors ça devrait aller, même si vous décidez de les appeler. 'CompanyThingamabob' et 'UserDoohickey'. La première étape, si vous travaillez pour une entreprise, est de voir s'il existe une convention d'entreprise pour la désignation. Si ce n’est pas le cas ou si vous ne travaillez pas pour une entreprise, créez vos propres termes en utilisant des termes qui vous semblent judicieux, transmettez-les à quelques collègues/amis de confiance qui codent au moins de manière informelle et intégrez tous les commentaires pertinents.

Appliquer la convention de quelqu'un d'autre, même si cela est largement accepté, si cela ne vous échappe pas est une erreur dans mon livre. Avant tout, je dois comprendre mon code sans faire référence à une autre documentation, mais en même temps, il doit être suffisamment générique pour qu'il ne soit pas incompréhensible pour quelqu'un d'autre dans le même domaine dans le même secteur.

Caroline · Answer

Je considérerais les modèles que vous utilisez pour votre système, les conventions de nommage/catalogage/regroupement des classes de classes ont tendance à être définies par le modèle utilisé. Personnellement, je m'en tiens à ces conventions car elles constituent le moyen le plus probable pour une autre personne de pouvoir récupérer mon code et de l'exécuter.

Par exemple, UserRecordsClerk pourrait être mieux expliqué comme étendre une interface générique RecordsClerk que UserRecordsClerk et CompanyRecordsClerk implémentent puis se spécialisent, ce qui signifie que vous pouvez consulter les méthodes de l'interface pour voir à quoi servent généralement ses sous-classes.

Consultez un livre tel que Design Patterns pour plus d’informations, c’est un excellent livre qui peut vous aider à préciser où vous visez votre code - si vous ne l’utilisez pas déjà! ; o)

Je pense que tant que votre modèle est bien choisi et utilisé dans la mesure appropriée, alors des noms de classe simples et peu inventifs devraient suffire!