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