Discussion :

[r0d]

Salut tout le monde,

bon voilà, ça faisait un petit moment que j'avais envie d'approfondir un peu le design pattern State ("patron état" en français), du coup j'ai écris ce petit article. Bien qu'il soit parfaitement impossible de traiter de façon exhaustive ce sujet, j'ai essayé de faire un petit peu le tour de la question, en partant des bases, afin que ce papier soit accessible au plus grand nombre.

Vous trouverez cet article sur la page suivante:
http://r0d.developpez.com/articles/dp-state-fr/

Toute remarque est la bienvenue. Vous pouvez poster vos commentaires sur ce fil.

[white_tentacle]

Bon article, qui résume assez bien beaucoup de manières compliquées d'aborder un problème simple .

Bon, j'exagère un peu, mais j'en pense quand même un peu aussi.

Je trouve par contre qu'il aurait été bon de commencer par un petit rappel sur Moore/Mealy (et notamment, préciser où est-ce qu'on mets les actions). Là, ça n'est pas très clair au long de l'article (notamment, Yatus met les actions sur les états, là où Qt semble les mettre sur les transitions (pas clair, je le soupçonne de faire les deux en fait)).

L'implémentation FSM me semble la plus proche de ce que j'ai tendance à faire pour du Moore. Je la modifierai quand même au minimum de la sorte :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class FSMstate { public:
   enum InputMessage {
      message_on = 0,
      message_off = 1,
      message_ack = 2
   };
   virtual void Message(InputMessage mess)  { cout << "undefined combo" << endl; }
};
 
class FSM {
public:
   FSM();
   void Message(FSMState::InputMessage mess)   { states[current]->Message(mess);  current = next[current][mess]; }
private:
   FSMstate*  states[3];
   int        current;
   int        next[3][3];
};
 
class A : public FSMstate { public:
   void Message(InputMessage mess)  { 
       switch(mess)
       {      
            case message_on:
               cout << "A, on ==> A" << endl;
               break;
            case message_off:
               cout << "A, off ==> B" << endl;
               break;
            case message_ack:
               cout << "A, ack ==> C" << endl;
               break;
       }
 };
 
FSM::FSM() {
   states[0] = new A; states[1] = new B; states[2] = new C;
   current = 1;
   next[0][FSMstate::message_on] = 0; next[0][FSMstate::message_off] = 1; next[0][FSMstate::message_ack] = 2;
   next[1][FSMstate::message_on] = 1; next[1][FSMstate::message_off] = 0; next[1][FSMstate::message_ack] = 2;
   next[2][FSMstate::message_on] = 2; next[2][FSMstate::message_off] = 2; next[2][FSMstate::message_ack] = 1; }

Sur un grand nombre d'états et d'entrées, il devient très lourd de devoir définir une fonction par entrée, pour chaque état. Je préfère alors un type énuméré qui permet de fournir un comportement par défaut pour toute entrée inattendue. Surtout, cela me permet de clarifier grandement l'écriture de la matrice de transition.

Ensuite, j'ai bien évidemment tendance à vouloir rerentrer ces classes états, qui ne fournissent que du comportement, dans le contexte. Je n'ai jamais compris le bénéfice à externaliser la choses dans ce cas précis. Ca rajoute un appel de fonction virtuel, et ça empêche de clarifier plus la matrice de transition (l'association état <-> numéro devient triviale, là où elle est relativement cachée sinon).


Pour revenir à Yatus, je n'aime pas du tout la séparation entre l'arrivée de l'évènement extérieur (UpdateCurPhase) et l'action (DoSomething). Cette opération est atomique, ça n'a pas vraiment de sens de faire UpdateCurPhase plusieurs fois avant DoSomething, ou inversement, non ? (ou j'ai loupé une subtilité).

Bon, je critique beaucoup, mais ça reste un bon article, expliquant bien les choses, et bien écrit .

[3DArchi]

Là, ça n'est pas très clair au long de l'article (notamment, Yatus met les actions sur les états, là où Qt semble les mettre sur les transitions (pas clair, je le soupçonne de faire les deux en fait)).

Salut,
Je dirais que les deux approches sont légèrement différentes :
-> Si ton automate réagit aux évènements, alors il peut être judicieux de mettre l'action sur la transition,
-> Si tu te bases sur l'état courant pour faire varier ton action, alors la transition n'a pas d'importance et les actions sont sur l'état.

[le petit dernier]

Miam miam j'en veux d'autres

Merci

[white_tentacle]

Salut,
Je dirais que les deux approches sont légèrement différentes :
-> Si ton automate réagit aux évènements, alors il peut être judicieux de mettre l'action sur la transition,
-> Si tu te bases sur l'état courant pour faire varier ton action, alors la transition n'a pas d'importance et les actions sont sur l'état.

C'est la différence Moore/Mealy, il y a pas mal de littérature là-dessus. Les deux sont équivalentes en terme de possibilité (on peut passer de l'une à l'autre et inversement).

Globalement, l'action sur les transitions est surtout rentable si tu as beaucoup d'évènements qui rebouclent sur le même "état structurel" tout en provoquant des action différentes --> en Moore, tu grimpes vite en nombre d'états.

Plus que la "logique" évènements/états, il faut surtout voir celui qui te donne le modèle le plus simple au final (moins d'états, moins de transitions).

Par contre, avoir à la fois des actions sur les états et les transitions, c'est un coup à se paumer et ne plus comprendre ce que fait le code (après, ça m'est arrivé de le faire, faute de temps).

[3DArchi]

C'est la différence Moore/Mealy, il y a pas mal de littérature là-dessus. Les deux sont équivalentes en terme de possibilité (on peut passer de l'une à l'autre et inversement).

Je connais pas Moore/Mealy. Mais en revanche, c'est clair que les deux approches sont équivalentes puisqu'il 'suffit' de considérer les méthodes présentes dans chaque état comme un évènement généré dans l'automate.

Plus que la "logique" évènements/états, il faut surtout voir celui qui te donne le modèle le plus simple au final (moins d'états, moins de transitions).

C'est aussi pour part lié à l'objectif que tu tires de ce pattern. A priori, dans le cadre d'un protocole, j'aurais tendance à utiliser un système d'évènements et mettre les actions sur les transitions. Dans une I.H.M., le gestionnaire de souris dépendant d'un état par exemple (modes édition/sélection/déplacement caméra, etc...), les actions seront plus probablement dans l'état. Ce dernier cas peut faire penser au du DP Strategy, mais je trouve plus parlant de parler de pattern Etat.

Par contre, avoir à la fois des actions sur les états et les transitions, c'est un coup à se paumer et ne plus comprendre ce que fait le code (après, ça m'est arrivé de le faire, faute de temps).

Je serais plus nuancé. Là je dirais que parfois c'est intéressant de mettre une partie dans la transition (en gros les actions d'entrée/sortie d'état pilotée par les transitions) et une partie dans l'état en lui-même (l'action à proprement parler). Mais au final, une même action donnée ne devrait pas se retrouver parfois dans la transition et parfois dans l'état. C'est là qu'on aurait de la confusion.

[r0d]

@white_tentacle: merci pour tes remarques pertinentes. Je ne connaissais pas Moore/Mealy, et effectivement, j'aurais pu en glisser un mot. Mais en fait, je ne voulais pas charger trop cet article, je souhaite qu'il reste très accessible. Il est déjà trop chargé à mon avis (comme tu dis, ça donne l'impression de chercher des trucs compliqués à partir d'un truc simple, et c'est ce que je voulais éviter). Donc bon, j'ai tout de même hésité, mais après réflexion, je vais laisser Moore/Mealy à un autre rédacteur

[Goten]

Hum bon article r0d . Par contre, juste un truc, certaines zone de code ne sont pas labellé C++ du coup y'a pas la syntaxe highlighting.

[r0d]

Hum bon article r0d . Par contre, juste un truc, certaines zone de code ne sont pas labellé C++ du coup y'a pas la syntaxe highlighting.

merci
pour les labels c++, j'ai modifié quelques trucs, mais la coloration est un peu étrange. Je ne peux rien y faire

[Goten]

Ah ben voilà, maintenant y'a la coloration syntaxique partout .

[_skip]

Avez-vous l'impression que ce pattern est overkill lorsque l'objectif est principalement de faire de la gestion d'erreur?

Style un port série :

état ouvert
- > open génère une exception (IllegalStateException)
- > close ferme le port
- > write écrit ds le port

état fermé
- > open ouvre le port
- > close génère une exception (IllegalStateException)
- > write génère une exception (IllegalStateException)

Vous avez des comportements différents des méthodes suivant un état, principalement dans le but d'autoriser ou non une action. Est-ce que dans ce genre de cas vous voyez l'utilité?

edit : petite correction d'une faute idiote sur write

[Médinoc]

close sur un port fermé ne devrait pas générer d'exception; tout au plus retourner une valeur de indiquant "c'est déjà fait"...

[white_tentacle]

close sur un port fermé ne devrait pas générer d'exception; tout au plus retourner une valeur de indiquant "c'est déjà fait"...

C'est un point de vue qui se défend. Mais j'ai quand même tendance à penser que si ton code ferme deux fois le port, il souffre probablement aussi d'autres tares :
- il utilise un port fermé en croyant qu'il est ouvert
- il peut ne pas fermer le port du tout

Fermer un port fermé, c'est une violation de contrat, finalement .

Pour en revenir à la question initiale, ce qui est un peu "overkill" dans un cas aussi simple, c'est surtout de sortir les états et les transitions de la classe.

PS : c'est moi ou tu as inversé le write sur port fermé ouvert ? write sur un port ouvert devrait marcher, sur un port fermé, non.

[Médinoc]

C'est un point de vue qui se défend. Mais j'ai quand même tendance à penser que si ton code ferme deux fois le port, il souffre probablement aussi d'autres tares :
- il utilise un port fermé en croyant qu'il est ouvert
- il peut ne pas fermer le port du tout

Fermer un port fermé, c'est une violation de contrat, finalement .

C'est là la différence de philosophie entre free() et fclose(). Personnellement, j'aime que mes fonctions de nettoyage soient... réflexives, si je me souviens bien du terme.
En clair, qu'elles mènent toutes au même état, même depuis l'état en question.

[3DArchi]

C'est là la différence de philosophie entre free() et fclose(). Personnellement, j'aime que mes fonctions de nettoyage soient... réflexives, si je me souviens bien du terme.
En clair, qu'elles mènent toutes au même état, même depuis l'état en question.

Le hic c'est que demander de fermer quelque chose de déjà fermée est signe d'un probable problème dans le scénario déroulé. J'ai vu des applis où on se basait sur cette propriété réflexive (utilisons ton terme tant que personne ne nous contredit) pour finalement fermer une connexion à beaucoup trop d'endroit 'au cas où'. Ce qui a inévitablement conduit à des bugs très pénibles à détecter et corriger

[_skip]

C'était un exemple pour illustrer un cas ou les States ne servent quasiment qu'à la gestion d'erreur, c'est à dire à détecter une mauvaise utilisation de la classe...
En bref j'ai dit ça parce que connaître les pattern c'est une chose, savoir détecter les situations où ils sont élégants sans qu'ils vous entraînenent sur la pente glissante de l'overengineering c'est une autre histoire.

Pour donner mes 5 centimes par rapport à la philosophie du close(), je dirai que ce sont deux philosophies différentes.

Si on voit les choses du point de vue java. Avec le close lanceur d'IllegalState ça donne à peu près ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SerialPort port = null; 
try
{
     port = new SerialPort(2); 
     port.open();
     port.write....
}
catch( IOException ex)
{
     ....
}
finally
{
     if( port != null )
           if( port.getState() == PortState.Open )
                   port.close();
}

Ou sinon :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SerialPort port = null; 
try
{
     port = new SerialPort(2); 
     port.open();
     port.write....
}
catch( IOException ex)
{
     ....
}
finally
{
     if( port != null )
            port.closeQuietly(); //un close sans exception qui vérifie l'état tout seul
}

Pas un énorme deal pour cette fermeture... La solution idéale étant selon moi les blocs ARM mais bon ils ont été refusés en java.

[Mindiell]

Bonjour,

J'ai plusieurs petites questions :
- A propos de l'implémentation GoF, tu dis

Une autre raison pour laquelle je n'aime pas trop cette implémentation c'est qu'elle pose un problème (un cas de conscience au moins) si l'on souhaite que les états puissent accéder à des données/fonctions non publiques du contexte.

Mais où, dans ton implémentation YaTuS, est-il possible d'accéder aux données privées ?


- Je cherche à gérer plusieurs états différents dans mon application (il s'agit d'un bot à travers Telnet). Je vais donc avoir besoin de différents états. J'aurai par exemple un état qui me dira si j'ai bien recu (à priori) toutes les données par Telnet et si je peux agir. J'aurai un autre de type comportemental qui créera des objectifs ou des commandes à effectuer par le bot. J'aurais un Etat qui me dira si le bot est en pause ou s'il peut agir, etc... Ce que je voyais, au départ, c'était un enum avec les états possibles (un enum par Etat) et des "méthodes privées" qui feraient les actions et les transitions. Pensez-vous que cela puisse être une bonne idée ?

Exemple rapide :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
class Bot
{
public :
 enum TelnetState
 {
  Waiting,
  Receiving,
  Idle
 }
 
 ManageBot();
private:
 //Ces trois methodes privées gèrent les actions et le changement d'état
 NothingReceived();
 SomethingReceived();
 SomethingSent();
 
 TelnetState mCurrentTelnetState;
};
 
ManageBot()
{
 switch (mCurrentTelnetState)
 {
 //Dans ce cas, Waiting et Receiving réagissent aux mêmes transitions
 //On aurait pu les regrouper, mais je préfère avoir du code lisible et
 //compréhensible
 case Waiting:
  if (TelnetConnection.Received())
  {
   SomethingReceived();
  }
  else
  {
   NothingReceived();
  }
  break;
 case Receiving:
  if (TelnetConnection.Received())
  {
   SomethingReceived();
  }
  else
  {
   NothingReceived();
  }
  break;
 case Idle:
  //Là on fait agir le bot puisque les données sont arrivées
  //On se basera alors sur son état de vie (en pause, en pas à pas, etc...)
  //pour voir si l'on peut le faire agir réellement
  //Et sur son état comportemental et sur l'état de l'environnement, etc...
  //pour voir ce qu'il souhaite faire
  break;
 }
}

Ca m'évite de multiplier des classes d'états, et tout est finalement géré par la classe principale, non ? Etant donné qu'il s'agit d'un premier bot, j'avance un peu à l'aveuglette niveau conception et je ne veux pas y plonger sans fin, mais avancer, quitte à revenir sur mon code par la suite.

[r0d]

Bonjour,

J'ai plusieurs petites questions :
- A propos de l'implémentation GoF, tu dis

Une autre raison pour laquelle je n'aime pas trop cette implémentation c'est qu'elle pose un problème (un cas de conscience au moins) si l'on souhaite que les états puissent accéder à des données/fonctions non publiques du contexte.

Mais où, dans ton implémentation YaTuS, est-il possible d'accéder aux données privées ?

Oui ce n'est pas très clair. En plus j'ai vu des erreurs dans le code, il va falloir que je revoie ça.
En fait, l'idée c'est que dans le cas du GoF, si les états veulent accéder à des données privées du contexte, il va falloir, d'une façon ou d'une autre, casser l'encapsulation du contexte.
Dans le cas du state "YaTuS", on peut stocker les données dont les états ont besoin dans les états eux-même. On peut le faire aussi dans le state du GoF, mais ça modifierais l'idée de départ de ce D.P. qui est que les états ne possèdent pas de données (et donc problème avec le new lors du changement d'état, etc.).


Quant à ton bot, c'est difficile de se prononcer comme ça avec si peu de détails. Le problème de ces questions de conception, c'est que á dépend vraiment énormément du contexte, et qu'il n'y a pas de réponse magique qui marche dans tous les cas.

De toutes façons, avant de te lancer dans l'implémentation, fais quelques diagrammes. Et en particulier un diagramme d'état, et éventuellement un ou des diagramme(s) de séquence. Et une fois ces diagrammes (bien) faits, la réponse viendra naturellement.

[Mindiell]

Dans le cas du state "YaTuS", on peut stocker les données dont les états ont besoin dans les états eux-même.

N'est-ce pas contraire au modèle objet ? Si la donnée est spécifique à la classe Game, que ferait cette donnée dans l'état ?

Quant à ton bot, [bla bla bla]la réponse viendra naturellement.

Bon, ben j'ai commencé avec mon idée et ca marche pas trop mal : c'était le but. Quand j'aurais plus avancé je pense que j'y reviendrai pour voir si c'est toujours bien ou s'il faut passer à un DP. Merci pour l'article en tout cas

[r0d]

N'est-ce pas contraire au modèle objet ? Si la donnée est spécifique à la classe Game, que ferait cette donnée dans l'état ?

C'est un bonne question effectivement. Enfin, disons que c'est une question que je me pose aussi
Et pour le moment, je suis arrivé à la conclusion que l'état d'un objet fait partie de cet objet. L'objet et ses états - en fait, l'objet et son état courant - peuvent être considérés, d'un point de vue métier, comme le même objet. Ça va à l'encontre du state du GoF, je suis d'accord, mais disons que c'est une autre façon de voir les choses, et donc, qui ne couvre pas exactement le même champ d'application.