Utilisation de "Base" dans un nom de classe

Question

Est-il acceptable d'utiliser le mot "Base" dans un nom de classe qui est le bas de l'arbre d'héritage?

J'ai toujours trouvé ça un peu faux, je me demandais si quelqu'un était d'accord avec moi. Par exemple, si je suis en train de refactoriser certains éléments de MyClassA et MyClassB en une classe de base commune, je serais tenté de créer une classe MyBaseClass dont les deux hériteraient.

Mais que se passe-t-il si jamais j'ai besoin de refactoriser MyBaseClass? MyBaseBaseClass? Maintenant c'est idiot. Je sais que Rocky Lhotka ne se soucie pas de son cadre AAPC, mais je suis toujours mal à l'aise avec les définitions de la programmation.

Pensées? Laissez-moi clarifier pourquoi Je m'inquiète même à ce sujet.

J'ai deux espaces de noms - MySpecificNamespace et MyCommonNamespace. MyNamespace utilise MyCommonNamespace, comme vous pouvez vous y attendre. Maintenant, j'aime utiliser au maximum les espaces de noms autant que possible pour décrire le contexte du problème, et éviter d'ajouter le contexte au nom de la classe. Ainsi, par exemple, considérez que j'ai une classe dans MyNamespace qui descend d'un dans MyCommonNamespace.

Option A

Je pourrait appel de cette

MySpecificClass: MyClass 
{ 
} 

Mais je suis d'ajouter 'spécifique' (le contexte) au nom - qui est redondant car il est déjà en MySpecificNamespace.

Option B

MyClass: MyCommonNamespace.MyClass 
{ 
} 

Vous pouvez voir comment nous pourrions se confondre ici, non?

Option C

Celui que je pense est fishy:

MyClass: MyBaseClass 
{ 
} 

Answer 1

Je pense qu'il devrait être évité sans doute, si possible, en faveur d'un identifiant qui décrit en fait ce qu'il est!

Cette question est difficile à répondre parce qu'elle est abstraite. Je pourrais, par exemple, envisager d'appeler la base de MyClassA et MyClassB, "MyClass".

Answer 2

Je pense que ça vaut la peine de wiki-fying cette question.

FWIW, je suis d'accord. J'essaie généralement de trouver un terme plus "générique" pour mes classes de base. Donc, si j'ai une classe "Client" et que j'ai besoin d'introduire une nouvelle classe de base, je choisirais "Contact" ou quelque chose plutôt que "CustomerBase".

Answer 3

Je joins à "non" pour exactement la raison de refactoring que vous avez citée.

Une classe doit être nommée d'après ce qu'elle représente logiquement, et rien d'autre que la classe Object est vraiment vraiment Base. Métaphysique FTW :)

---

re: l'option B, il n'y a rien de confusion à propos de

namespace MySpecificNamespace 
{ 
    MyClass: MyCommonNamespace.MyClass 
    { 
    } 
} 

Answer 4

J'ai tendance à ajouter un suffixe de base au nom de la classe de base que si elle existe du point de vue technique (pour partager du code), et ne constitue pas vraiment une classe utilisable seule (donc toutes ces classes sont abstraites). Ce sont des cas assez rares cependant, et devraient être évités juste comme des classes auxiliaires.

Answer 5

Je suis également du côté du campement ... placez une Base là-bas aujourd'hui et dans 6 mois quelqu'un écrasera une classe MyDerivedClass dans votre base de code pendant que vous ne regardez pas.

Answer 6

Je suggère aussi Non, mais pas coulé dans le béton ...

Après mantra OO, votre système de nommage devrait mieux représenter les objets sous-jacents que le code est censé être l'encapsulation. Il ne devrait pas vraiment y avoir de 'méta-langage', lié à la composition syntaxique réelle du langage de programmation choisi. Cela dit, si votre objet est vraiment abstrait et que vous ne le voyez pas changer de sitôt, il y a un argument selon lequel l'ajout de 'Base' aide à la lisibilité générale.

Comme dans la plupart des cas, il n'y a pas de bonne et de mauvaise réponse - cela dépend de la disposition générale de votre base de code, de ce que ce code spécifique est censé représenter et du style interne que vous avez. Essayez juste d'être cohérent.

La base est-elle utilisée ailleurs?

Answer 7

"Résumé" préfixe peut-être?

Answer 8

En Java j'ai tendance à fournir une implémentation de base d'une interface Foo dans une classe abstraite FooBase. Je pense que c'est parfaitement correct, et rend la connexion à l'interface très claire et régulière.

Sans l'interface, j'appellerais la classe de base abstraite Foo.

Answer 9

Je vais généralement avec IFoo pour l'interface et AbstractFoo pour l'implémentation squelettique, qui est un mélange de conventions .NET et Java.

Answer 10

Je suis d'accord, AbstractFoo est une solution décente. J'essaie de choisir des noms qui n'ont pas besoin d'adjectifs supplémentaires. J'éviterais d'utiliser Base.

Answer 11

Les classes qui ont le même nom que leurs classes parentes ne me dérangent pas. En Java java.sql.Date étend java.util.Date. Ceci est très ennuyeux car vous devez spécifier la classe exacte que vous voulez importer ou bien spécifier le nom de la classe (y compris package/namespace).

Personnellement, je préfère nommer les choses telles qu'elles sont; Si une classe de base ou abstraite existe seulement pour fournir une implémentation partielle de quelque chose, et ne représente pas l'interface pour cette chose, il est souvent acceptable de mettre le mot Abstract ou Base dans son nom. Cependant, si cette classe représente aussi l'interface, alors vous devriez simplement la nommer après ce qu'elle fait.

Par exemple, en Java, nous avons l'interface de connexion (pour les connexions DB). C'est juste appelé Connection, pas IConnection. Vous l'utiliser comme ceci:

Connection con = getConnectionFromSomewhere(); 

Si vous faites un pilote JDBC et la nécessité de mettre en œuvre la connexion, vous pourriez avoir un ConnectionBase ou AbstractConnection qui est la couche inférieure du détail de la mise en œuvre de votre connexion particulière. Vous pouvez avoir

abstract class AbstractConnection implements Connection 

class OracleConnection extends AbstractConnection 

ou quelque chose comme ça. Cependant, les clients de votre code ne voient jamais AbstractConnection et ne voient pas OracleConnection, ils ne voient que Connection. Donc, en général, les classes censées être généralement utiles doivent être nommées d'après ce qu'elles représentent/font, alors que les classes qui sont des aides pour la maintenance/l'organisation du code peuvent être nommées après ce qu'elles sont. * Ps Je déteste nommer les interfaces avec I. Est-ce que les gens nomment toutes leurs classes avec C? C'est 2009! votre IDE peut vous dire quel type d'objet c'est, dans le cas impair où cela importe même s'il s'agit d'une interface ou d'une classe.

Answer 12

"Toutes vos BaseClass nous appartiennent."

Je suis avec un non définitif, avec une seule exception. Si vous écrivez une application pour gérer des installations militaires ou des stades de baseball, allez-y.