Cet article parle de la manière d'utiliser au mieux le Pattern Etat, issu du livre Design Patterns: Elements of Reusable Object-Oriented Software par Erich Gamma et consors. Le Pattern Etat, lorsque bien utilisé, permet de concevoir des applications de qualité (facile à comprendre, à débugger, à maintenir, à faire évoluer) sans augmentation notable des charges de travail (temps de maintenance diminués, plus grande évolutivité).

Dans cet article, les exemples sont donnés en C++. J'ai choisi le C++ car vous pouvez très facilement adapter le code à d'autres langages comme Java. L'inverse n'est pas forcément évident (un oubli dans l'implémentation C++ peut conduire à des fuites mémoire, par exemple).

Les diagrammes ont été réalisés avec Dia, logiciel gratuit et multiplateforme pour faire des schémas de toutes sortes (UML et autres).

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) :

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 :

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.