JAVA - Normes pour les Noms des classes

En tant qu'ingénieur informatique spécialisé dans le développement de systèmes en Java, je me suis créé plusieurs règles afin de rendre le développement d'un projet plus productif, mieux documenté et plus facilement maintenable. Parmi ces règles, je me suis défini une nomenclature pour les noms des classes. Vous trouverez cette liste triée par ordre alphabétique. Favorisant grandement le classement alphabétique, j'ai défini des suffixes plutôt que des préfixes. Dans certains cas, l'usage de suffixes est moins standard (ex XxxAbstract vs AbstractXxx), malgré tout, c'est ce que j'utilise et préconise.

Classe abstraite racine de différentes implémentations.

On préfèrera XxxAbstract à AbstractXxx qui est moins standard mais qui permet de garder les classes d'un même type ensemble (lorsque trier alphabétiquement).

Classe abstraite qui implémente les méthodes d'une interface sans rien faire.

ex: MouseAdapter, ...

Classe Business Object.

J'utilise souvent la notion d'objet métier ou de 'business object'. Dans certains cas, pour identifier de tels objets j'utilise la convention XxxBO.
Mais attention, d'une manière générale, il ne faut pas qu'un nom contiennent le type. Plus qu'un type, la notion de 'busines object' peut-êre vue de manière sémantique.

Classe ou interface de configuration.
Une classe qui contient une configuration (ex: ConsoleConfig).
Afin de rentre les noms à la fois courts et compréhensible, on utilisera Config plutôt que Configuration. Quelque soit votre choix, soyez consistent et utiliser toujours la même règle pour une même contraction.

Implémentation par défaut d'une interface ou d'une classe abstraite.

Dans de nombreux cas on favorisera les trois niveaux :

• Xxx : Abstraction sous forme d'interface
• XxxAbstract : Implementation abstraite partielle
• XxxDefault : Implémentation par défaut.

Classe ou interface de conversion.
Classe qui est utilisée pour convertir des données, des logs...

ex:

• DateStringConverter : Convertit une date en String et réciproquement.
• LogConverter : Convertit des logs...

Une bonne pratique consiste à créer ses propres instances d'exception. Toujours utiliser un nom XxxException pour bien les identifier.

Interface ou Classe factory.

• Interface : En général ne contiendra qu'une méthode newXxx(--).
• Classe : Permet de créer des objets.

Exemples :

• Factory with prototypes.

Builder de Factory.
Permet de créer une factory. Dans ce cas, la Factory sera définie comme une interface.

• static newFactory() : retourne l'instance d'une factory

Exemple : voir framework XML contenu dans le JDK.

Implementation par défaut.

Exemples : interface LabelIcon / class LabelIconImpl

Classe avec un main pour lancer une application.
Bien souvent les gens font une classe dérivant de classe Swing (par exemple JFrame) avec une méthode main pour lancer leur application.
Je pense qu'il est préférable de séparer la classe de lancement des classes graphique. Dans cette classe on retrouvera les appels aux initialisations, et l'appel à la classe dérivant de JFrame correspondant à notre application.
Cela permet par exemple de lancer dans la même VM (virtual machine) plusieurs applications, de modifier les initailisation et d'utiliser les même interface graphique, ...

Interface permettant de lier des modules.

Quand on veut faire un module indépendant du reste du système, on pourra regrouper toutes ces intéractions dans une interface afin de rendre ce module indépendant.
Les classes qui voudront utiliser ce module devront alors définir une implémentation de cette interface pour utiliser le module.
Dans le cas où c'est possible, on préfèrera l'usage d'évenement plutot que de définir une telle interface. (Ex : modification du contenu d'une liste, ...).
Voir aussi XxxVM - XxxViewManager.

Cas classique(s) d'utilisation :

• Module GUI : Un module ayant une interface graphique représentant des données et pouvant réagir avec le système (Extension du pattern MVC).
• XxxViewManager : le manager du module
• XxxView : la vue
• XxxModel : le modèle, contient toutes les données utiles
• XxxLink : les liens avec le système (de type action par exemple)

Classe ou interface Manager.
Une classe qui manage des data, des log, ... (ex: DataMgr, LogMgr).
La même remarque que XxxConfig - XxxConfiguration : Utiliser plutôt XxxMgr et surtout soyez consistent.

Interface permettant d'accéder à des donneés.

On l'utilisera souvent quand on utilise le pattern MVC (Model-View-Controler).
Voir XxxVM - XxxViewManager pour plus de détails.

Interface Owner.

• En général ne contiendra qu'une méthode getXxx() : Xxx

Interface Prototype.

• En général ne contiendra qu'une méthode newXxx() : Xxx

Un prototype est une sorte de factory, il peut instancier des objets. On utilisera un prototype pour instancier toujours le même type d'objet contrairement à une factory qui peut instancier des objets différents.
Un Classe qui implémente une interface de type prototype peut créer d'autres instances de cette même Classe.

Cas classique(s) d'utilisation :

• Factory : Permet de créer une factory qui crée des instances en fonction d'un nom ou autre paramètre.
• Pour cela, créer un map de prototypes indexés par les noms.
• On évite de faire un switch en utilisant la map.
• Permet d'avoir une implémentation de la factory qui est indépendante des objets à créer. En effet on peut utiliser une methode addPrototype(name, prototype)

Exemples :

• Factory with prototypes.

Classe ou interface Reader.

Classe Singleton.

• static getInstance() : retourne l'instance par défaut du Singleton.
• static getInstance(--) : Dans le cas où l'on veut gérer une liste de singletons de même type.
• constructeur private, ou protected si on veut prévoir plusieurs implémentations possibles (utilisation de sous classes).
• static initWith(XxxSingleton) : L'avantage important d'un singleton par rapport à l'utilisation de méthodes statiques réside dans le fait que l'on peut définir plusieurs implémentations. Dans le cas où je veux pouvoir définir ou paramétrer une instance de ce singleton sans passer par des méthodes publiques, j'utilise la méthode initWith pour initialiser le singleton avec une instance particulière.

Dans de nombreux cas, on pourra ne pas utiliser le suffixe Singleton. Par contre on indiquera dans les commentaires de la classe qu'il s'agit d'un singleton.

Exemples :

• Factory with prototypes.

Interface de deuxième niveau avec 'setter'.

Exemple: LabelIcon LabelIconSet LabelIconImpl.

• interface LabelIcon
• getLabel() : String
• getIcon(int) : Icon
• interface LabelIconSet
• implements LabelIcon
• setLabel(String)
• putImage(int, Icon)
• classe concrète LabelIconImpl
• implémentation par défaut

Classe qui permet de gérer les évènements par délégation.

Les méthode de cette classe sont en général :

• addXXXListener(XXXListener)
• removeXXXListener(XXXListener)
• fireXXX(XXXEvent)

ex: PropertyChangeSupport, ...

Une interface template définit les méthodes qui permettent par exemple à un objet de se représenter selon un template.

Classe utilitaire.

En général, la classe sera abstraite et ne contiendra que des méthodes statiques.
Pour des questions de performance, on pourra mettre toutes les méthodes finales.
Si plusieurs implémentations sont possibles, on utilisera un singleton plutôt qu'une classe Tools avec des méthodes statiques.

Classe View utilisée comme view dans le pattern MVC (Model-View-Controler).

Voir XxxVM - XxxViewManager pour plus de détails.

Classe ViewManager utilisé comme manager dans le pattern MVC (Model-View-Controler).

En général le viewManager recevra en parametre le model de type XxxModel, et construira une vue de type XxxView.
Voir aussi XxxLink.

Classe ou interface Writer.