Conventions de dénomination pour les classes abstraites

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.

Dans Framework Design Guidelines p 174 déclare:

Évitez de nommer les classes de base avec un suffixe «Base» si la classe est destinée à être utilisée dans les API publiques.

Aussi: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

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

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)

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.

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".

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.