Conventions de dénomination pour les classes abstraites

102

Je me souviens distinctement qu'à un moment donné, la directive préconisée par Microsoft était d'ajouter le suffixe «Base» à une classe abstraite pour éviter le fait qu'elle était abstraite. Par conséquent, nous avons des classes comme System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBaseet, bien sûr, System.Collections.CollectionBase.

Mais j'ai remarqué que, dernièrement, beaucoup de classes abstraites du Framework ne semblent pas suivre cette convention. Par exemple, les classes suivantes sont toutes abstraites mais ne suivent pas cette convention:

  • System.DirectoryServices.ActiveDirectory.DirectoryServer

  • System.Configuration.ConfigurationElement

  • System.Drawing.Brush

  • System.Windows.Forms.CommonDialog

Et c'est exactement ce que je pourrais faire en quelques secondes. Je suis donc allé chercher ce que la documentation officielle avait à dire, pour m'assurer que je n'étais pas fou. J'ai trouvé les noms de classes, de structures et d'interfaces sur MSDN dans Design Guidelines for Developing Class Libraries . Curieusement, je ne trouve aucune mention de la directive d'ajouter "Base" à la fin du nom d'une classe abstraite. Et les directives ne sont plus disponibles pour la version 1.1 du Framework.

Alors, suis-je en train de le perdre? Cette directive a-t-elle jamais existé? Est-ce qu'il vient d'être abandonné sans un mot? Ai-je créé de longs noms de classes tout seul ces deux dernières années pour rien?

Quelqu'un m'a jeté un os ici.

Mise à jour, je ne suis pas fou. La ligne directrice existait. Krzysztof Cwalina s'en plaint en 2005.

.net naming-conventions abstract-class Mike Hofer
la source
Si vous lisez cet article, Krzysztof se plaint simplement de recevoir "un ensemble de recommandations" - pas nécessairement que ces recommandations soient officielles de Microsoft. Je me souviens avoir lu les directives MS et les avoir vus recommander de ne pas le faire.
John Rudy le
1
Je l'ai lu, même si c'est la première fois que je me souviens avoir vu cet article en particulier. C'est un soulagement, en fait. Je n'ai jamais vraiment aimé la recommandation. Cela m'évitera beaucoup de grognements à partir de maintenant. :)
Mike Hofer

Réponses:

19

De plus, si la classe abstraite a quelques membres statiques qui seront utilisés, la 'Base' peut devenir moche.

Joel Coehoorn
la source
14

Je ne me souviens pas d'une telle directive. Je pense que vous devriez utiliser la dénomination qui a du sens. Parfois, la classe abstraite est uniquement conçue pour fournir des fonctionnalités communes à certaines classes (en tant qu'outil), qui, je pense, devraient avoir le suffixe. Cependant, dans certains cas, vous souhaitez l'utiliser comme base d'une hiérarchie de polymorphisme qui n'est pas complète elle-même. 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 un ButtonBase comme paramètre. Il est conçu pour fournir une fonctionnalité minimale aux sous-classes. Cependant, vous pouvez traiter a ConfigurationElementcomme une entité qui a différentes formes mais qui n'est pas complète sur elle-même (et donc elle est abstraite)

Mehrdad Afshari
la source
11

Parfois, Base est toujours nécessaire, en particulier lorsque vous fournissez à la fois une classe concrète et une classe abstraite que quelqu'un peut étendre pour créer une implémentation concrète.
par exemple, Controller et ControllerBase (en fait, Controller est également abstrait, mais fournit beaucoup plus de fonctionnalités que ControllerBase)

Le suffixe de base est moche lors de la programmation contre une interface, donc je pense que la directive de Microsoft de ne pas l'utiliser s'applique lorsque la classe abstraite est principalement utilisée comme une interface. Probablement ce qu'ils signifient par API publique.

Le fait est qu'il existe des cas où il n'y a pas de meilleure alternative à l'utilisation du suffixe de base.

James
la source
4
Je suis d'accord. Je travaille dans un système de flux qui analyse le contenu de différentes sources. Nous utilisons dans l'API publique une interface nommée IFeedParser , et en interne nous utilisons une classe abstraite de base contenant une fonctionnalité commune nommée BaseFeedParser
Rui Jarimba
1

Je comprends la tendance à éviter un suffixe de base, mais je comprends également la nécessité de certains suffixes. Maintenant, un commentaire de cet article suggère d'utiliser "Type" comme suffixe comme deuxième choix pour ne pas en utiliser. Je pense que c'est déroutant, mais l'idée que «un tel mot sans engagement tendrait à indiquer que c'est une classe non engagée» m'a collé.

Comme alternative: je préférerais utiliser "Kind" comme suffixe pour déclarer l'objet comme "de ou appartenant à une race ou une famille spécifiée" ( Wiktionnaire: -kind ).

Exemple: DataProvideret ReflectiveDataProvidersont tous les deuxDataProviderKind

Inspiré de la biologie où par exemple "canis lupus" appartient à la famille "Canoidea", qui se traduit très grossièrement par "dog-ish".

Kooooons
la source
1

Microsoft déclare, à:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"✓ CONSIDÉRER de terminer le nom des classes dérivées par le nom de la classe de base. Ceci est très lisible et explique clairement la relation. Quelques exemples de ceci dans le code sont: ArgumentOutOfRangeException, qui est une sorte d'exception, et SerializableAttribute, qui est un genre d'attribut. Cependant, il est important de faire preuve de discernement lors de l'application de cette directive. Par exemple, la classe Button est une sorte d'événement Control, bien que Control n'apparaisse pas dans son nom. "

D'une manière générale, cela exclut implicitement l'utilisation de "Base" dans le nom.

Sam Jazz
la source