Manager"? [fermé]'/> Manager"? [fermé]'/> Manager"? [fermé]'/> Naming Classes - Comment éviter d'appeler tout un "<WhatEver> Manager"? [fermé] | abulletproofidea.com

Question Naming Classes - Comment éviter d'appeler tout un " Manager"? [fermé]


Il y a longtemps, j'ai lu un article (je crois une entrée de blog) qui m'a mis sur la bonne piste pour nommer les objets: Soyez très très scrupuleux à propos de nommer des choses dans votre programme.

Par exemple, si mon application était (en tant qu'application métier typique) traitant des utilisateurs, des entreprises et des adresses, j'aurais un User, une Company Et un Address classe de domaine - et probablement quelque part un UserManager, une CompanyManager Et un AddressManager surgirait qui gère ces choses.

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

L'article que j'ai lu a recommandé d'utiliser des noms très spécifiques. Si c'était une application C ++ et UserManagerLe travail consistait à allouer et libérer les utilisateurs du tas, il ne gérait pas les utilisateurs mais gardait leur naissance et leur mort. Hmm, peut-être que nous pourrions appeler cela un UserShepherd.

Ou peut-être le UserManagerLe travail consiste à examiner les données de chaque objet Utilisateur et à signer les données de façon cryptographique. Ensuite, nous aurions un UserRecordsClerk.

Maintenant que cette idée est restée avec moi, j'essaie de l'appliquer. Et trouver cette idée simple incroyablement difficile.

Je peux décrire ce que font les classes et (tant que je ne glisse pas dans le codage rapide et sale) les cours que j'écris font exactement 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èle dans mon esprit (fréquemment des modèles de conception fournissent facilement les noms d'objet, par exemple un usine)

  • Factory - Crée d'autres objets (nommage pris dans le motif de conception)
  • Shepherd - Un berger gère la vie des objets, leur création et leur fermeture
  • Synchronizer - Copie des données entre deux ou plusieurs objets (ou hiérarchies d'objets)
  • Nanny - Aide les objets à atteindre un état "utilisable" après la création - par exemple en câblant vers 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 pensez-vous nommer des choses pas si importantes ou fausses?

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 des classes Java sans 'Manager'


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

Voici un petit résumé de ce que j'ai appris de cette question en attendant.

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

D'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 conseil pour la route:

Ne pas nommer la paralysie. Oui, les noms sont très importants mais ils ne sont pas assez importants pour perdre énormément de temps. Si vous ne pouvez pas trouver un bon nom en 10 minutes, passez à autre chose.


934
2017-12-08 13:26


origine


Réponses:


J'ai demandé à un question similaire, mais si possible, j'essaie de copier les noms déjà dans le framework .NET, et je cherche des idées dans les frameworks Java et Android.

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 obtenir particulièrement prosey pourpre avec les noms et aller pour des choses comme Minder, Overseer, Supervisor, Administrator, et Master, mais comme je l'ai dit, je préfère le garder comme les noms de framework auxquels vous êtes habitué.

Certains autres suffixes communs (si c'est le bon terme) que vous trouverez également dans le framework .NET sont:

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

153
2017-12-08 12:59



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

Les 20 premiers 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

88
2017-12-08 13:13



Je suis tout à fait pour de bons noms, et j'écris souvent sur l'importance de prendre grand soin en choisissant des noms pour des choses. 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 signifier. 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 l'appelez une nounou parce qu'il s'occupe d'autres choses comme une vraie nounou s'occupe des bébés ou des enfants. C'est OK dans un discours informel, mais pas OK (à mon avis) pour nommer les classes dans le code qui devra être maintenu par qui sait qui sait quand.

Pourquoi? Parce que les métaphores dépendent de la culture et dépendent souvent aussi de l'individu. Pour vous, nommer une classe «nounou» peut être très clair, mais peut-être que ce n'est pas clair pour quelqu'un d'autre. Nous ne devrions pas compter sur cela, sauf si vous écrivez du code uniquement pour un usage personnel.

En tout cas, la convention peut faire ou défaire une métaphore. L'utilisation de "factory" lui-même est basée sur une métaphore, mais celle qui existe depuis un certain temps et est actuellement assez bien connue dans le monde de la programmation, donc je dirais que c'est sûr à utiliser. Cependant, "nounou" et "berger" sont inacceptables.


50
2017-12-08 13:18



Nous pourrions faire sans xxxFactory, xxxManager ou xxxRepository classes si nous avons modélisé le monde réel correctement:

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

;-)


39
2017-12-08 13:02



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

Je suppose que c'est juste qu'une classe Manager monolithique n'est pas bonne, mais utiliser 'Manager' n'est pas mauvais. Au lieu de UserManager, nous pouvons le décomposer en UserAccountManager, UserProfileManager, UserSecurityManager, etc.

«Manager» est un bon mot car il montre clairement qu'une classe ne représente pas une «chose» dans le monde réel. 'AccountsClerk' - comment suis-je censé dire si c'est une classe qui gère les données d'utilisateur, ou représente quelqu'un qui est un commis aux comptes pour leur travail?


31
2017-12-08 13:12



Puisque vous êtes intéressé par des articles dans ce domaine, vous pourriez être intéressé par l'article d'opinion de Steve Yegge "Execution in the Kingdom of Nouns":

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


19



Quand je me retrouve à penser à utiliser Manager ou Helper dans un nom de classe, je considère que c'est une odeur de code qui signifie que je n'ai pas encore trouvé la bonne abstraction et / ou que je viole la principe de responsabilité unique, donc refactoring et mettre plus d'effort dans la conception rend souvent le nommage beaucoup plus facile.

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 métier ou de classes d'infrastructure technique.

Les classes de modèle métier peuvent être difficiles, car elles sont différentes pour chaque domaine. Il y a quelques termes que j'utilise beaucoup, comme Policy pour des classes de stratégie dans un domaine (par exemple, LateRentalPolicy), mais ceux-ci découlent généralement d'essayer de créer un "langage omniprésent"que vous pouvez partager avec les utilisateurs professionnels, en concevant et en nommant des classes afin qu'ils modélisent des idées, des objets, des actions et des événements réels.

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 des noms de modèles de design dans les noms de classes, comme InsertUserCommand,  CustomerRepository, ou SapAdapter. Je comprends la préoccupation de communiquer la mise en œuvre au lieu de l'intention, mais les modèles de conception marient ces deux aspects de la conception de classe - au moins quand vous avez affaire à l'infrastructure, où vous voulez la mise en œuvre conception être transparent même si vous cachez les détails.


16