Conventions de nommage pour les classes abstraites
je me souviens très bien qu'à une certaine époque, la ligne directrice préconisée par Microsoft était d'ajouter le suffixe" Base " à une classe abstraite pour éviter qu'elle ne soit abstraite. Par conséquent, nous avons des classes comme System.Web.Hosting.VirtualFileBase , System.Configuration.ConfigurationValidatorBase , System.Windows.Forms.ButtonBase , et, bien sûr, System.Collections.CollectionBase .
mais j'ai remarqué que, dernièrement, beaucoup de classes abstraites dans le cadre ne semblent pas suivre cette convention. Par exemple, les classes suivantes sont toutes abstraites mais ne le sont pas. suivre cette convention:
-
System.DirectoryServices.ActiveDirectory.DirectoryServer -
System.Configuration.ConfigurationElement -
System.Drawing.Brush -
System.Windows.Forms.CommonDialog
et c'est exactement ce que je pouvais faire en quelques secondes. Je suis donc allé voir ce que la documentation officielle avait à dire, pour m'assurer que je n'étais pas fou. J'ai trouvé le les noms des Classes, des structures et des Interfaces sur MSDN à les lignes directrices de conception pour le développement des bibliothèques de classe . Curieusement, je ne trouve aucune mention de la ligne directrice pour ajouter "Base" à la fin du nom d'une classe abstraite. Et les lignes directrices ne sont plus disponibles pour la version 1.1 du cadre.
alors, est-ce que je perds la boule? A cette directive jamais exister? Il a simplement été abandonnée sans un mot? Ai-je été la création de des noms de classe longs tout seul depuis deux ans pour rien?
que Quelqu'un me jette un os ici.
mise à Jour Je ne suis pas fou. La ligne directrice existait. Krzysztof Cwalina s'en plaint en 2005.
6 réponses
Dans Cadre des lignes Directrices de Conception p 174 états:
éviter nommer les classes de base avec un suffixe "de Base" si la classe est destinée à être utilisée dans les IPA publics.
aussi: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx
Aussi, si la classe abstraite a quelques membres statiques qui sera utilisée la "Base" peut devenir laid.
Je ne me souviens pas d'une telle ligne directrice. Je crois que vous devriez utiliser l'appellation qui fait sens. Parfois, la classe abstraite est seulement conçue pour fournir une fonctionnalité commune à certaines classes (comme un outil), qui je pense devrait avoir le suffixe. Toutefois, dans certains cas, vous voulez l'utiliser comme la base d'un polymorphisme de la hiérarchie qui n'est pas complet. Dans ces cas, je suggère de nommer comme une classe normale.
comme vous le voyez, vous ne déclarerez probablement pas une méthode qui accepte une ButtonBase comme paramètre. Il est conçu pour fournir des fonctionnalités minimales pour les sous-classes. Cependant, vous pourriez traiter un ConfigurationElement comme une entité qui a des formes différentes mais il n'est pas complet sur lui-même (et donc il est abstrait)
parfois Base est encore nécessaire, surtout quand vous fournissez à la fois une classe concrète et une classe abstraite pour quelqu'un d'étendre pour créer une mise en œuvre concrète.
par exemple Controller et ControllerBase
(en fait, Controller est aussi abstrait, mais offre nettement plus de fonctionnalités que ControllerBase)
suffixe de Base est laid lors de la programmation contre une interface, donc je pense que la ligne directrice de Microsoft de ne pas l'utiliser s'applique lorsque le classe abstraite est principalement utilisé comme une interface. Probablement ce qu'ils veulent dire par API publique.
le fait est qu'il y a des cas où il n'y a pas de meilleure solution que d'utiliser le suffixe de Base.
je comprends la tendance à éviter un suffixe de Base, mais je comprends aussi la nécessité de quelque suffixe. Maintenant, un commentaire de cet article suggère d'utiliser "Type" comme suffixe comme second choix pour ne pas en utiliser. Je crois que c'est déroutant, mais l'idée que "un tel mot sans engagement tendrait à indiquer qu'il s'agit d'une classe non engagée" m'a retenu.
comme Alternative: préférez l'utilisation de "Genre" comme suffixe à l'état de l'objet comme "appartenant à une race ou à la famille" ( Wiktionnaire: -genre ).
exemple: DataProvider et ReflectiveDataProvider sont tous deux DataProviderKind
inspiré de la biologie où par exemple" canis lupus "appartient à la famille" Canoidea", qui se traduit très grossièrement par"chien-ish".
Microsoft déclare, à:
✓ envisager de terminer le nom des classes dérivées par le nom de la classe de base. C'est très lisible et explique la relation clairement. Quelques exemples de cela dans le code sont: Argumentoutfrangeexception, qui est une sorte d'Exception, et SerializableAttribute, qui est un type de l'Attribut. Cependant, il est important de faire preuve de jugement raisonnable dans l'application de cette ligne directrice; par exemple, la classe bouton est une sorte d'événement de contrôle, bien que le contrôle n'apparaisse pas dans son nom."
en général, cela exclut implicitement l'utilisation de" Base " dans le nom.