I. Les enjeux▲
Plutôt qu'un long discours, j'ai préféré vous faire une démonstration simple de ce que peut vous apporter le Pattern Etat.
Voici ce à quoi peut très vite ressembler le code d'une application (par exemple une application réseau) :
Sélectionnez
int MaClasse::run() {
...
while (executer) {
if ((etat == ETAT1) || (etat == ETAT2)) {
// du code
} elseif (etat == ETAT3) {
// du code
} else {
// encore du code
}
switch (etat) {
case ETAT2:
case ETAT3:
case ETAT5:
// encore du code
if (etat == ETAT5) {
// du code, uniquement si on est dans l'état 5
}
break;
case 1:
// du code, pour l'état 1
// pas de break, histoire d'ajouter à la confusion ambiante
case 4:
// encore du code
}
...
}
}C'est illisible, difficile à tracer, sujet à de nombreux bugs, pas du tout évolutif, etc. Pour des applications complexes, cela devient très vite ingérable.
Maintenant, regardons ce code :
Sélectionnez
int MaClasse::run() {
etat = EtatInitial::getInstance() ;
while( etat->executer(this) ) ;
return etat->codeRetour() ;
}C'est beaucoup plus propre :
- l'implémentation est encapsulée dans différentes classes Etat
(1 comportement = 1 classe Etat) ; - l'exécution est facile à tracer
(mise en évidence des états du système, ainsi que des transitions entre états).
Nous verrons ceci à partir de la section suivante.