Discussion :

[onlytoine]

Bonjour,

Je me pose une question existentielle : existe-t-il une référence / une convention sur le nommage des classes ?

Je ne parle pas des minuscules/majuscules, mais plutôt des règles comme :

- les implémentations par défaut : <MaClasse>Impl
- un service... : <MaClasse>Service
- un adaptateur : <MaClasse>Adapter
- une classe abtraite : Abstract<MaClasse>
- etc...

Merci !

Anthony

[CyberChouan]

J'ajouterais à cette liste:

MaclasseTest pour les tests unitaires (JUnit) d'une classe
IMaClasse pour une interface
etc.

Oui, ces conventions existent et sont fréquemment employées. Maintenant, je ne saurais dire si il existe un ouvrage de référence donnant une liste complète...

D'après ce que j'ai pu voir, chaque projet fixe (pendant la phase de spécifications) les conventions de codage qui seront employées (et éventuellement validées automatiquement par des règles CheckStyle)

[onlytoine]

Oui, voilà mais là on m'a demandé de justifier leur utilisation

[KuTaY]

A ton avis, quel serait l'intêret d'un tel nommage?

[onlytoine]

Pour moi, l'intérêt principal est que c'est une "convention" utilisée par la majorité des développeurs. Et donc, il est plus facile de prendre en main du code structuré de cette manière.

Voyez-vous d'autres intérêts ?

[Sanguko]

Pour ma part, je ne vois pas l'interet de cette convention.

Je trouve que ca alourdit le nom des classes, au risque de masquer le veritable role d'une classe.

D'ailleurs dans les packages de base, cette convention n'est pas utilisée.

[onlytoine]

Comment fais tu par exemple lors que tu as une notion représentée par une interface et une implémentation par défaut ?

La plupart des développeurs écrivent :

- Toto (ou IToto) pour l'interface
- TotoImpl (j'au aussi vu TotoDefault, TotoBase,...) pour l'implémentation

Comment les nommes-tu ?

Anthony

[KiLVaiDeN]

Salut,

Je préfère grandement la notation :
Toto
TotoImpl

A la suivante :
IToto
Toto

Le problème de "IToto", c'est que quand on fait de l'injection, on se retrouve à appeler des méthodes d'une soit disant interface. Hors ce n'est qu'un détail que ce soit une interface, c'est plutôt un contrat, et bien un vrai objet qu'on manipule derrière.

Donc faire des appels sur "Toto.getCoucou()" me parait plus logique que de faire un appel sur "IToto.getCoucou".

La classe d'implémentation avec Impl à la fin, permet de vraiment se rendre compte que ce n'est qu'une implémentation. Le vrai contrat se trouve dans l'interface. Donc l'ensemble reste cohérent.

Ensuite, nommer les objets ( "TotoService" ) permet de gérer plus facilement les intercepteurs. Par exemple, pour rendre tous les "services" transactionnels, il suffit d'intercepter toutes les classes se terminant par "*Service". C'est aussi à ça que sert le nommage déclaratif. Au niveau des logs aussi, on voit tout de suite ce qu'il se passe.

Vous me direz : on peut également le savoir avec les noms de packages. Pourquoi pas les deux dans ce cas ?

A+

[Duc Lebowski]

Pour ce genre de cas, voilà ce que j'utilise mais c'est complètement subjectif :

interface : IStrategieExport (le I a été récupéré de crosoft c#)

classe abstraite de base (si besoin) : StrategieExportBase

classe d'implémentation : StrategieExportExcel

class de test : StrategieExportExcelTest

Enfin je dis ça je dis rien, après tout ça dépend aussi des noms donnés aux packages, ...

[billynirvana]

On retrouve la convention de nommage dans de nombreux projets open source Apache:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IInterface
AAbstract

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
ClasseObserver
ClasseBean
ClasseFactory
ClasseManager
ClasseSingleton

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int ivalue
boolean bvalue
String svalue

Je l'ai adoptée. Elle me convient bien!

[natha]

D'ailleurs dans les packages de base, cette convention n'est pas utilisée.

Normal pour certains points car ça n'a pas forcément sa place, mais certaines sont utilisées et il y en a d'autres : un listener <Classe>Listener, son implémentation par défaut <Classe>Adapter, l'événement <Classe>Event, beaucoup de classes abstraites sont nommées Abstract<Classe> et leur implémentation par défault Default<Classe>, etc...

Les conventions c'est pour faciliter la maintenance et la compréhension du code. L'idéal étant d'avoir une convention le plus proche possible de ce qui est fréquemment utilisé.

[onlytoine]

L'idéal étant d'avoir une convention le plus proche possible de ce qui est fréquemment utilisé.

Voilà, et donc ce que je demandais c'est : y-a-t'il une liste des conventions les plus utilisées et pourquoi elles ont été choisies ?

Merci déjà pour toutes ces réponses intéressantes !

Anthony

[Sanguko]

Normal pour certains points car ça n'a pas forcément sa place, mais certaines sont utilisées et il y en a d'autres : un listener <Classe>Listener, son implémentation par défaut <Classe>Adapter, l'événement <Classe>Event, beaucoup de classes abstraites sont nommées Abstract<Classe> et leur implémentation par défault Default<Classe>, etc...

Les conventions c'est pour faciliter la maintenance et la compréhension du code. L'idéal étant d'avoir une convention le plus proche possible de ce qui est fréquemment utilisé.

Sais tu (ou quelqu'un d'autre) s'il existe une convention pour les packages du jdk?

[EDIT] Oups, la question vient d'être posée [/EDIT]

[natha]

Voilà, et donc ce que je demandais c'est : y-a-t'il une liste des conventions les plus utilisées et pourquoi elles ont été choisies ?

Il n'y a pas de recommandations spéciales à ma connaissance. Tout dépend des frameworks que tu vas utiliser. Tout ce qui a été indiqué sur ce thread est utilisable. Il faudrait synthétiser :

• Service => <Classe>Service
• Implémentation du service => <Classe>ServiceImpl ou <Classe>ServiceDefault
• Interface => I<Classe>
• Classe abstraite => Abstract<Classe>
• Implémentation par défaut d'une classe abstraite => Default<Classe>
• etc.

Après tout dépend de comment tu travailles. Avec Eclipse 3.3 on peut facilement retrouver tous nos services par exemple en cherchant les types nommés "*Service", tous les validateurs en cherchant "*Validator", etc. Il n'y a pas de bonne ou mauvaise règle à partir du moment ou la convention est choisie avec un minimum de bon sens.

[Patriarch24]

Le nom d'une classe/interface doit refléter son utilisation, son sens... C'est pourquoi ajouter un 'I' devant un nom d'interface me semble tout a fait inutile. Une interface se nommant IDrawable n'a aucun sens : Drawable est bien suffisant.

[onlytoine]

Merci à tous... ça fait avancer (un peu) le chmilblick...