Dois-je ajouter un préfixe «abstrait» à mes classes abstraites?
Supposons que j'ai une classe abstraite nommée Task.
Existe-t-il une norme ou une convention qui suggère que je devrais le nommer AbstractTask à la place?
Selon Effective Java (Item 18) de Bloch, le préfixe Abstract est une convention utilisée dans un cas spécial.
Vous pouvez combiner les vertus des interfaces et des classes abstraites en fournissant une classe d'implémentation squelettique abstraite pour accompagner chaque interface non triviale que vous exportez. ... Par convention, les implémentations squelettiques sont appelées AbstractInterface, où Interface est le nom de l'interface qu'elles implémentent.
Mais Bloch souligne également que le nom SkeletalInterface aurait eu un sens, mais conclut que
la convention abstraite est désormais solidement établie.
Comme d'autres réponses l'ont souligné, il n'y a généralement aucune raison d'appliquer cette convention de dénomination à toutes les classes abstraites.
Il n'y a pas de convention. Tout dépend de ce qui vous aidera, en tant que développeur, à coder plus rapidement et mieux, et à aider les autres à comprendre votre code.
Demandez aux personnes qui verront et conserveront le code. Que préfèrent-ils voir? Qu'est-ce qui leur facilitera la tâche? Nommez-le ensuite en fonction de ce qu'ils aimeraient.
Sur une autre note, Conventions de code pour le Java: 9. Conventions de dénomination ne suggère aucune exigence:
Les noms de classe doivent être des noms, en casse mixte avec la première lettre de chaque mot interne en majuscule. Essayez de garder vos noms de classe simples et descriptifs. Utilisez des mots entiers - évitez les acronymes et les abréviations (sauf si l'abréviation est beaucoup plus largement utilisée que la forme longue, comme URL ou HTML).
Non. Intellisense me dira trivialement si c'est abstrait, donc vous violez simplement DRY ici.
C'est un peu une question de préférence (mais une mauvaise pratique limite), mais la plupart des gens n'aiment pas voir une partie des qualificatifs au nom de la classe.
La plupart des IDE rendront ces informations facilement accessibles de toute façon, il n'est donc pas nécessaire de les mettre dans le nom, et il sera plus simple de les omettre. Cela rappelle la notation hongroise pour la dénomination des variables, et c'est certainement considéré comme une mauvaise forme de nos jours. Je recommande simplement de l'appeler Task.
Dans .NET, l'utilisation de "Base" comme suffixe pour désigner une classe de base abstraite est souvent observée. Je m'en remets aux autres réponses pour savoir s'il s'agit d'une pratique courante en Java.
À mon avis, le nom d'une entité ne doit pas transmettre d'informations sur sa structure de type, mais sur sa sémantique. Il n'est donc pas logique de définir votre classe comme "AbstractSomething" si l'abstraction ne fait pas partie de son objectif d'exécution. Le fait qu'il s'agit d'une classe abstraite de base est visible pour le programmeur et n'a pas besoin d'être reflété dans le nom.
Cependant, si rend parfait pour appeler une implémentation d'une fabrique abstraite, une AbstractFactory, car cela se rapporte à l'intention de la classe.
En général, privilégiez les conventions de dénomination qui aident à transmettre le plus d'informations sur l'objectif de votre classe.
De même, restez à l'écart de SomethingImpl. Peu importe que ce soit une implémentation et non une classe de base. Si votre hiérarchie de classes est conçue correctement pour l'héritage, quelqu'un pourrait en hériter. Il n'y aurait sûrement aucune valeur à ajouter plus de suffixes "Impl" ou d'autres artefacts. Il n'y a également aucune valeur à ajouter un suffixe "Interface" ou un préfixe "I".
Considérer:
IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl
Par opposition à:
Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
<-- Ferrari
<-- Trabi
Je préfère de loin ce dernier.
Ceci, à certains égards, similaire à la abus flagrant de la Notation hongroise cette dernière lui a donné sa mauvaise réputation , comme les gens ont commencé à tort à interpréter cela oblige les développeurs à préfixer leurs variables avec un indicateur du type de la variable. Bien que cela puisse parfois avoir ses utilisations (surtout si vous êtes paresseux pour rechercher la définition du type), c'est surtout inutile. L'idée originale de Simonyi avec la notation hongroise était de l'utiliser comme mnémonique pour rappeler au développeur les capacités de l'entité, pas de son type.
Une bonne règle d'or consiste à ne pas inclure dans un nom des propriétés qui sont évidentes d'après la syntaxe. Étant donné qu'en Java, vous devez marquer une classe abstraite avec le mot-clé abstract bien nommé, je ne l'inclurais pas dans le nom. En C++, par exemple, le cas n'est pas aussi clair, mais au moins le compilateur vous dira quand vous avez utilisé incorrectement une classe abstraite. Dans quelque chose comme Python encore une fois, nommer explicitement une classe abstraite en tant que telle n'est pas une mauvaise idée.
L'exception habituelle à la règle est lorsque le nom est ambigu. Si, pour une raison quelconque, il existe une sous-classe concrète Task (dans d'autres exemples, cela peut être plus judicieux, mais peu importe), alors bien sûr, utilisez AbstractTask.
protected abstract SomeClass { }
Cela me dit que c'est une classe abstraite. L'ajout d'un préfixe est un tautologie et anti-modèle et n'est pas approprié dans la plupart des cas, voir le lien où il parle de package local étant une exception par exemple.
Dans la plupart des cas, les classes Abstract ne devraient pas faire partie d'une API accessible au public, si c'est le cas, il devrait y avoir vraiment une bonne raison et une bonne raison devrait fournir un nom évidemment bon autre que AbstractSomeClass.
Dans la plupart des cas, si vous ne pouvez pas trouver un nom plus descriptif, vous devrez probablement faire une refonte.
Mes cinq cents, vous aurez probablement des implémentations de cette classe abstraite et elles seront nommées 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask' etc. Il n'y aura donc pas de conflit de nom entre votre 'Task' abstraite et eux.
De plus, Word "abstrait" concerne la syntaxe du langage, pas les entités du domaine métier, donc je préfère ne pas l'utiliser comme partie du nom.
D'un autre côté, dans une réponse, j'ai vu un extrait de J.Bloch Effective Java qui dit que l'utilisation de "abstrait" comme partie d'un nom est une pratique bien établie. Mais de toute façon dans les conventions de code officielles Java Java il n'y a rien à ce sujet.