Dois-je ajouter un préfixe «abstrait» à mes classes abstraites? [fermé]

Supposons que j'ai une classe abstraite nommée Task.

Existe-t-il une norme ou une convention qui suggérerait que je le nomme à la AbstractTaskplace?

Selon le Java efficace de Bloch (point 18), le préfixe abstrait 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? Ensuite, nommez-le en fonction de ce qu'ils aimeraient.

Sur une autre note, les conventions de code pour le langage de programmation Java: 9. Les conventions de dénomination ne suggèrent 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 disponibles 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 le nommage 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.

Cela, à certains égards, similaire à l' utilisation abusive flagrante de la notation hongroise que celle-ci lui a donné sa mauvaise réputation , car les gens ont commencé à tort à l'interpréter comme obligeant 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 évidentes d'après la syntaxe. Étant donné qu'en Java, vous devez marquer une classe abstraite avec le abstractmot-clé 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, 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 une tautologie et anti-modèle et n'est pas approprié dans la plupart des cas, voir le lien où il parlepackage local être une exception par exemple.

Dans la plupart des cas, les Abstractclasses ne doivent 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.

De plus, le mot «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. Il en est peut-être ainsi. Mais de toute façon dans les conventions officielles du code java, il n'y a rien à ce sujet.

Si vous travaillez en équipe, c'est toute l'équipe qui doit décider si vous devez préfixer les classes abstraites avec "Résumé".

Si vous travaillez seul, c'est à vous de décider, pas à moi ni à personne d'autre sur ce site.

Je ne suis pas un développeur Java (INAJD?) Et je ne connais pas la nomenclature standard pour de telles choses, mais je pense que cela Tasksemble suffisamment abstrait pour qu'il puisse être autonome tel quel.

Et si vous voulez écrire une AbstractSyntaxTreeclasse abstraite ? Ou peut-être juste un résumé SyntaxTree?

Ce n'est pas conventionnel et cela peut facilement dérouter les gens.

Je l'ai fait. J'ai ajouté «Abstract» comme préfixe à ma classe abstraite nommée AbstractOperation. La raison pour laquelle j'ai fait cela était qu'il y avait un autre paquet qui avait une classe non abstraite nommée Operation, et cela a aidé mon équipe et les programmeurs qui ont pris le relais plus tard en évitant toute confusion entre les deux.