Quelle est la meilleure approche pour nommer les classes ?[fermé]

Question

Il est notoirement difficile de trouver des noms précis et précis pour les classes.Bien fait, il rend le code plus auto-documenté et fournit un vocabulaire pour raisonner sur le code à un niveau d'abstraction plus élevé.

Les classes qui implémentent un modèle de conception particulier peuvent recevoir un nom basé sur le nom du modèle bien connu (par ex.FooFactory, FooFacade) et les classes qui modélisent directement les concepts de domaine peuvent tirer leurs noms du domaine problématique, mais qu'en est-il des autres classes ?Existe-t-il quelque chose comme un thésaurus de programmeur vers lequel je peux me tourner lorsque je manque d'inspiration et que je veux éviter d'utiliser des noms de classe génériques (comme FooHandler, FooProcessor, FooUtils et FooManager) ?

Answer 1

Je citerai quelques passages de Modèles de mise en œuvre par Kent Beck :

Nom de superclasse simple

« [...] Les noms doivent être courts et percutants.Cependant, pour que les noms soient précis, semble parfois nécessiter plusieurs mots.Un moyen de sortir de ce dilemme est en choisissant une métaphore forte pour le calcul.Avec une métaphore à l’esprit, Même les mots isolés apportent avec eux une riche réseau d’associations, de connexions, et ses implications.Par exemple, dans l' Cadre de dessin HotDraw, mon premier le nom d’un objet dans un dessin était Objet de dessin.Ward Cunningham est venu avec la métaphore de la typographie :un Le dessin est comme un imprimé, mis en page page.Les éléments graphiques d’une page sont chiffres, de sorte que la classe est devenue Chiffre.Dans le contexte de la métaphore, Chiffre est à la fois plus courte, plus riche et plus plus précis que Objet de dessin."

Nom de sous-classe qualifié

"Les noms de sous-classes ont deux fonctions.Ils doivent communiquer quelle classe ils sont et comment ils sont différents....] Contrairement aux noms des racines des hiérarchies, les noms de sous-classe ne sont pas utilisés presque aussi souvent dans la conversation, ils peuvent donc être expressifs au prix d'être concis.[...]

Donnez des sous-classes qui servent de racines des hiérarchies leurs propres noms simples.Par exemple, Dessin à chaud a une classe Poignée qui présente les opérations de montage de la figure lorsqu'une figure est sélectionnée.On l'appelle simplement, Poignéemalgré la prolongation Chiffre.Il y a toute une famille de poignées et ils ont des noms comme Poignée extensible et Poignée de transparence.Parce que Poignée est la racine de sa propre hiérarchie, elle mérite une simple nom de superclasse plus qu’un nom qualifié nom de la sous-classe.

Une autre ride en dénomination des sous-classes est les hiérarchies de niveau multiple....] Plutôt que de constituer aveuglément les modificateurs de la superclasse immédiate, pensez au nom du point de vue du lecteur.À quel cours a-t-il besoin de savoir que ce cours est?Utilisez cette superclasse comme base du nom de la sous-classe. "

Interface

Deux styles de dénomination des interfaces dépendent de la façon dont vous envisagez les interfaces.Les interfaces en tant que classes sans implémentations doivent être nommées comme s’il s’agissait de classes (Nom de superclasse simple, Nom de sous-classe qualifié).L’un des problèmes de ce style de Le nommage est que les bons noms sont utilisés avant que vous n’arriviez aux classes de nommage.Un interface appelée Déposer a besoin d'une classe d'implémentation appelée quelque chose comme FichierActuel, Fichier Béton, ou (beurk !) FichierImpl (à la fois un suffixe et un abréviation).D’une manière générale, le fait de communiquer qu’il s’agit d’un abstract est important, que l’objet abstrait soit implémenté en tant qu’objet ou une superclasse est moins importante.Le report de la distinction entre interfaces et superclasses est bien >supporté par ce style de nommage, ce qui vous permet de Libre à vous de changer d’avis plus tard si cela > devient nécessaire.

Parfois, la dénomination des classes en béton est tout simplement plus importante pour la communication que de cacher l'utilisation des interfaces.Dans ce cas, préfixez les noms d’interface avec « I ».Si l'interface est appelée FichierIF, la classe peut être simplement appelée Déposer.

Pour une discussion plus détaillée, achetez le livre !Ça en vaut la peine!:)

Answer 2

Optez toujours pour MyClassA, MyClassB - Cela permet un joli tri alpha.

Je plaisante!

C'est une bonne question, et c'est quelque chose que j'ai vécu il n'y a pas si longtemps.Je réorganisais ma base de code au travail et j'avais des problèmes pour savoir où mettre quoi et comment l'appeler.

Le réel problème?

J'avais des cours qui en faisaient trop.Si vous essayez de respecter les principe de responsabilité unique cela rendra tout beaucoup plus agréable.Plutôt qu'un système monolithique Gestionnaire d'impression classe, vous pourriez le diviser en Gestionnaire de pages , Formateur de pages (et ainsi de suite) et ensuite avoir un maître Imprimante classe qui rassemble tout cela.

Dans ma réorganisation, cela m'a pris du temps, mais j'ai fini par regrouper beaucoup de code en double, j'ai rendu ma base de code beaucoup plus logique et j'ai beaucoup appris en matière de réflexion avant de lancer une méthode supplémentaire dans une classe :D

Je voudrais pas recommandez cependant de mettre des éléments tels que les noms de modèles dans le nom de la classe.L'interface des classes devrait rendre cela évident (comme cacher le constructeur pour un singleton).Il n'y a rien de mal avec le nom générique, si la classe répond à un objectif générique.

Bonne chance!

Answer 3

L'excellent discours de Josh Bloch sur bonne conception d'API a quelques bons conseils :

• Les classes doivent faire une chose et bien la faire.
• Si une classe est difficile à nommer ou à expliquer, c'est probablement qu'elle ne suit pas les conseils du point précédent.
• Un nom de classe doit communiquer instantanément ce qu’est la classe.
• Les bons noms génèrent de bons designs.

Si votre problème est de savoir comment nommer les classes internes exposées, vous devriez peut-être les consolider dans une classe plus grande.

Si votre problème consiste à nommer une classe qui fait beaucoup de choses différentes, vous devriez envisager de la diviser en plusieurs classes.

Si c'est un bon conseil pour une API publique, cela ne peut faire de mal à aucune autre classe.

Answer 4

Si tu es coincé avec un nom, parfois tu le donnes simplement n'importe lequel un nom à moitié raisonnable avec un engagement à le réviser plus tard est une bonne stratégie.

Ne soyez pas paralysé par les noms.Oui, les noms sont très importants, mais ils ne le sont pas suffisamment pour perdre énormément de temps.Si vous ne parvenez pas à trouver un bon nom en 10 minutes, passez à autre chose.

Answer 5

Si un bon nom ne me vient pas à l’esprit, je me demanderais probablement s’il n’y a pas un problème plus profond : la classe sert-elle un bon objectif ?Si tel est le cas, le nommer devrait être assez simple.

Answer 6

Si votre "FooProcessor" traite réellement les foos, n'hésitez pas à lui donner ce nom simplement parce que vous disposez déjà d'un BarProcessor, d'un BazProcessor, etc.En cas de doute, il vaut mieux être évident.Les autres développeurs qui doivent lire votre code n'utilisent peut-être pas le même thésaurus que vous.

Cela dit, plus de spécificité ne ferait pas de mal pour cet exemple particulier.« Processus » est un mot assez large.Est-ce vraiment un "FooUpdateProcessor" (qui pourrait devenir "FooUpdater"), par exemple ?Vous n'avez pas besoin d'être trop "créatif" en matière de dénomination, mais si vous avez écrit le code, vous avez probablement une assez bonne idée de ce qu'il fait et de ce qu'il ne fait pas.

Enfin, rappelez-vous que le nom de classe nu n'est pas tout ce que vous et les lecteurs de votre code devez faire - il y a généralement également des espaces de noms en jeu.Ceux-ci peuvent souvent donner aux lecteurs suffisamment de contexte pour voir clairement à quoi sert réellement votre classe, même si son nom brut est assez générique.