111 votes

Conventions d'appellation pour les classes abstraites

Je me souviens très bien qu'à une certaine époque, la ligne directrice imposée par Microsoft consistait à ajouter le suffixe "Base" à une classe abstraite pour éviter qu'elle ne soit abstraite. Ainsi, 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 Framework ne semblent pas suivre cette convention. Par exemple, les classes suivantes sont toutes abstraites mais ne respectent pas cette convention :

  • System.DirectoryServices.ActiveDirectory.DirectoryServer

  • System.Configuration.ConfigurationElement

  • System.Drawing.Brush

  • System.Windows.Forms.CommonDialog

Et c'est juste ce que j'ai pu trouver en quelques secondes. J'ai donc cherché à savoir ce que la documentation officielle avait à dire, pour m'assurer que je n'étais pas fou. J'ai trouvé le Noms des classes, des structures et des interfaces sur MSDN à l'adresse Directives de conception pour le développement de bibliothèques de classe . Curieusement, je ne trouve aucune mention de la directive consistant à 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, est-ce que je perds la tête ? Cette directive a-t-elle jamais existé ? A-t-elle été abandonnée sans mot dire ? Est-ce que j'ai créé de longs noms de classe 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.

0 votes

Si vous lisez cet article, Krzysztof se plaint simplement d'avoir reçu "un ensemble de recommandations", sans nécessairement que ces recommandations soient officielles de Microsoft. Je me souviens avoir lu les directives de MS et les avoir vues déconseiller cette pratique.

1 votes

Je l'ai lu, mais c'est la première fois que je me rappelle avoir vu cet article. C'est un soulagement, en fait. Je n'ai jamais vraiment aimé la recommandation. Cela m'épargnera bien des grognements à partir de maintenant :)

72voto

Iain Holder Points 7930

Sur Directives de conception du cadre p 174 déclare :

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

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

21voto

Joel Coehoorn Points 190579

De plus, si la classe abstraite possède quelques membres statiques qui seront utilisés, la "base" peut devenir désagréable.

15voto

Mehrdad Afshari Points 204872

Je ne me souviens pas d'une telle directive. Je pense que vous devriez utiliser le nommage qui a du 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. Cependant, dans certains cas, vous voulez l'utiliser comme la base d'une hiérarchie de polymorphisme qu'elle n'est pas complète elle-même. Dans ces cas, je suggère de la 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. Elle est conçue pour fournir une fonctionnalité minimale aux sous-classes. Cependant, vous pourriez traiter un ConfigurationElement comme une entité qui a différentes formes mais qui n'est pas complète sur elle-même (et donc abstraite)

12voto

James Points 41

Parfois, Base est encore nécessaire, notamment 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 Base est laid lorsqu'on programme contre une interface, donc je pense que la recommandation de Microsoft de ne pas l'utiliser s'applique lorsque la classe abstraite est principalement utilisée comme une interface. C'est probablement ce qu'ils entendent par API publique.

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

4 votes

Je suis d'accord. Je travaille sur 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 des fonctionnalités communes, appelée BaseFeedParser

3voto

Kooooons Points 67

Je comprends que l'on veuille éviter un suffixe de base, mais je comprends aussi que l'on ait besoin de un peu de Suffixe. Maintenant, un commentaire de cet article suggère d'utiliser le "Type" comme suffixe en deuxième choix ou de ne pas en utiliser. Je pense que cela prête à confusion, mais l'idée qu'"un mot aussi peu engageant aurait tendance à indiquer qu'il s'agit d'une classe non engagée" m'a marqué.

Comme alternative : Je préférerais utiliser "Kind" comme suffixe pour énoncer l'objet comme "de ou appartenant à une race ou une famille déterminée" ( Wiktionnaire : -genre ).

Exemple : DataProvider et ReflectiveDataProvider sont tous deux DataProviderKind

Inspiré par la biologie où, par exemple, "canis lupus" appartient à la famille des "Canoidea", ce qui se traduit très approximativement par "chien".

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X