IV. Bonnes pratiques de conception▲
Voici quelques conseils pour une bonne utilisation du pattern Etat.
IV-A. Proscrire les copier/coller▲
Il peut arriver que plusieurs états aient un comportement identique (ou très similaire) pour une ou plusieurs de leurs méthodes. Pourtant, en aucun cas il ne doit y avoir de copier/coller dans un programme (c'est le signe d'une mauvaise conception et la source de nombreux problèmes).
Pour éviter les copier/coller, il existe plusieurs techniques (mettre le code commun dans une méthode/fonction spécifique, utiliser le pattern Template Method, etc).
Il est déconseillé de partager le code commun à plusieurs états par simple héritage. Rien ne dit en effet que vous arriverez à organiser vos classes selon une hiérarchie logique. De plus, cela nuit à l'évolutivité de votre application (s'il existe des contraintes liées à la hiérarchie des classes, on ne peut plus ajouter de nouveaux états comme on le souhaite).
On peut également s'appuyer sur d'autres patterns tels que Strategy.
IV-B. Organisation en modules▲
Pour éviter les collisions de noms, il est nécessaire d'organiser les différents états en modules. Pour ce faire, on utilisera les spécificités du langage de programmation utilisé (namespace, package…).
En pratique, la super classe Etat fait partie intégrante de l'interface de la classe principale et fait donc partie du même module (namespace ou package). Ce sont les classes héritant de la classe Etat qui doivent être définies dans un sous-module :
En C++▲
En C++, on met les différents états de la classe dans un namespace à part.
À ce titre, il est vivement recommandé d'utiliser une convention de nommage pour les différents namespace et de s'y tenir. On pourra par exemple prendre le mot « Etat » et lui apposer le nom de la classe principale pour définir le namespace. (ex-: Etat_MaClasse )
On aura ainsi, dans le fichier .h :
namespace Etat_UneClasse {
// définition des différents états de UneClasse
}et dans le fichier .cpp implémentant le comportement des états, afin de ne pas répéter le namespace à chaque fois :
using namespace Etat_UneClasse ;En Java▲
En Java, il existe deux façons de faire :
- utiliser les packages ;
- utiliser les classes internes (nested classes).
Sur le principe, les packages Java sont comparables aux namespaces du C++. On aura alors 1 fichier pour chaque classe définie (certains environnements autorisent la définition de plusieurs classes dans un même fichier, mais ce n'est pas très propre). Concrètement, cela veut dire que le développeur se retrouvera souvent avec plusieurs fichiers d'ouverts en même temps: un pour chaque état qu'il est en train de regarder, mais c'est un moindre mal avec l'amélioration des IDE.
Une classe interne, c'est une classe définie à l'intérieur d'une autre :
class UneClasse {
...
class UneClassInterne {
...
}
}Ceci est une spécificité de Java.
Voir ce lien: nested classes (site de Sun)
Dans ce cas, les différents états seront définis dans le même fichier, et plus précisément à l'intérieur de la même classe, ce qui ne facilite pas la visibilité et rend l'ajout de nouveaux états plus compliqué.
L'utilisation de classes internes peut éventuellement se justifier dans le cas de classes ne comprenant que très peu d'états, que ces états soient simples et quasi « immuables » (non sujets à des changements fréquents dans l'implémentation). Dans l'immense majorité des cas, on aura recours aux packages.
|
Sections suivantes: Discussion autour du pattern Etat (avantages, inconvénients, applications) |