cas d'étude: pattern state

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.

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:

---

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 ;).

Citation:

---

Envoyé par white_tentacle

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.

Miam miam j'en veux d'autres

Merci

Citation:

---

Envoyé par 3DArchi

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

Citation:

---

Envoyé par white_tentacle

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.

Citation:

---

Envoyé par white_tentacle

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.

Citation:

---

Envoyé par white_tentacle

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.

@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 ;)

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.

Citation:

---

Envoyé par 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.

---

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

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

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

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"...

Citation:

---

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.

Citation:

---

Envoyé par white_tentacle

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.

Citation:

---

Envoyé par Médinoc

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

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:

---

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:

---

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.

Bonjour,

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

Citation:

---

Envoyé par r0d

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:

---

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.

Citation:

---

Envoyé par Mindiell

Bonjour,

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

Citation:

---

Envoyé par r0d

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.

Citation:

---

Envoyé par r0d

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 ?

Citation:

---

Envoyé par r0d

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

Citation:

---

Envoyé par Mindiell

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 :aie:
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.

Perso je serais encore un peu plus bourrin que ça :
Implémenter la classe de façon compacte et une fois qu'elle fonctionne, écrire quelques tests unitaires sur l'interface publique.
Ensuite on peut voir comment tu peux la refactorer, quel comportement peut être extrait ainsi que ce que ça implique en terme de passage de contexte.

Peut être que tu te rendras compte que finalement appliquer ce pattern amène plus de problèmes qu'il n'en résout dans ce cas précis. C'est une possibilité et ça arrive assez souvent dans le code de certains stagiaires que j'ai vu travailler. Ils partent du principe que parce que c'est un DP c'est forcément la bonne solution, et au final ils tournent un truc simple en usine à gaz en ajoutant des classes et des interfaces très rigides qui nuisent plus qu'autre chose.

On évalue la qualité d'une implémentation par sa simplicité, la clarté de son code et sa maintenabilité. Les DP sont juste des outils proposés qui peuvent aider à atteindre cet objectif dans certaines situations, rien de plus.

Citation:

---

Envoyé par _skip

Perso je serais encore un peu plus bourrin que ça :
Implémenter la classe de façon compacte et une fois qu'elle fonctionne, écrire quelques tests unitaires sur l'interface publique.
Ensuite on peut voir comment tu peux la refactorer, quel comportement peut être extrait ainsi que ce que ça implique en terme de passage de contexte.

Peut être que tu te rendras compte que finalement appliquer ce pattern amène plus de problèmes qu'il n'en résout dans ce cas précis. C'est une possibilité et ça arrive assez souvent dans le code de certains stagiaires que j'ai vu travailler. Ils partent du principe que parce que c'est un DP c'est forcément la bonne solution, et au final ils tournent un truc simple en usine à gaz en ajoutant des classes et des interfaces très rigides qui nuisent plus qu'autre chose.

On évalue la qualité d'une implémentation par sa simplicité, la clarté de son code et sa maintenabilité. Les DP sont juste des outils proposés qui peuvent aider à atteindre cet objectif dans certaines situations, rien de plus.

---

+1

En fait, moi je vois plus les DP comme une sorte de série d'exercices. Il est bon de les comprendre et de les appliquer hors de tout contexte (juste pour tester et vérifier qu'on a bien compris), car cela permet de comprendre tout un tas de mécanismes qu'offre la poo, mais ils ne doivent pas être considérés comme des "recettes miracles". Ils sont d'ailleurs totalement passés de mode; il n'y a que moi pour écrire encore des trucs dessus :aie: (sans doute mon côté anticonformiste)

Mais c'était d'ailleurs un peu le propos de cet article: à partir d'un D.P. on peu faire milles variations (toutes celles qu'on souhaite en fait), et il ne faut pas considérer un DP comme un "moule" dans lequel on met notre code, mais comme une sorte de guide qui donne juste des idées générales.

Noussommes d'accord, d'où mes interrogations et la solution non DP que j'ai commencé à utiliser !
Merci encore,

Je suis en train de chercher des infos sur diverses implémentations du state pattern, et donc suis tombé sur cet article.

Il y a plusieurs points que j'aimerai commenter à son sujet:

* modèle initial:
"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."

Problème solvable très simplement (je suis surpris de n'avoir vue cette méthode nulle part jusqu'a présent d'ailleurs):
Mettre la classe ancêtre en amie de la classe de contexte et mettre dans la classe State les getters/setters souhaités. Cela permets de donner aux classes concrètes un accès limité aux données de la classe Context:

Code:

---

1 2 3 4 5 6 7 8

class Context { friend class State; int m_i; int getI( void ) const; void setI( int i ); };

---

J'utilise à l'origine cette astuce pour le design pattern visitor ( je n'aime pas trop l'idée de mettre des attributs en accès public... ) mais ça fonctionne aussi pour les machines à état, je pense.

Il ne reste donc en inconvénient que celui de la dépendance de l'état abstrait vers le contexte, les autres états ayant uniquement besoin de connaître le nom du contexte. Pas de #include "context.hpp", mais "class Context;" malgré tout nécessaire, donc.

* YATUS:
Une façon d'éviter la recompilation de Game dès qu'on ajoute un état, serait d'utiliser un conteneur de pointeurs de GameState, par exemple std::vector<GameState*> (l'utilisation de smart pointers serait plus qu'appropriée ici, mais c'est pour l'exemple) qui soit initialisé dans le constructeur.
Ainsi, la déclaration de Game n'aurait pas à dépendre aussi fortement des états ( bien que ça ne change rien pour l'implémentation ) et on évite nombre de recompilations à la moindre modification/ajout d'un état ( par exemple, on évite la recompilation de main() dans l'exemple ).

* Les états sous forme de singleton
Faire hériter chaque état concret d'une classe singleton ( donc, double héritage) évite de refaire la logique singleton à chaque fois.
Vu qu'on travaille avec des références, il serait aussi possible de supprimer 2 des 3 références/pointeurs: quel intérêt y a-t-il à conserver des références vers des variables globales ( aka singleton ) que l'on peut récupérer de toute façon via une fonction ( méthode statique de la classe singleton )?

Note de fin:
Pourquoi ne pas utiliser les surcharges d'opérateurs de cast et de constructeurs pour gérer les transitions?
Si je veux pouvoir transformer un état A en état B, un état B en état A ou C, et un état C en objet B, il suffit d'écrire les opérateurs de cast et/ou constructeurs correspondant, après tout.
Si on utilise une construction à base de RAII ( le point fort du C++ par rapport à nombre de langages, selon moi ) on peut ainsi se passer de devoir implémenter des classes dédiées à cette tâche.
Quant au "problème" des new/delete, je ne le vois pas: il n'y a pas de données, donc la construction est très rapide, non?

Salut Freem, merci pour tes remarques.
Je vais te donner mon point de vue sur tout ça, mais je ne prétend pas détenir la vérité. Surtout qu'il faut garder à l'esprit que si les patrons de conception tentent de dresser des règles universelles, chaque programme est un cas particulier, donc différent. Par conséquent, quelque chose peut être considéré comme mauvais dans le cas général, mais peut être bon dans un cas particulier. Et inversement.

Citation:

---

Envoyé par Freem

* modèle initial:
"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."

Problème solvable très simplement (je suis surpris de n'avoir vue cette méthode nulle part jusqu'a présent d'ailleurs):
Mettre la classe ancêtre en amie de la classe de contexte et mettre dans la classe State les getters/setters souhaités.

---

C'est justement ça le "cas de conscience" dont je parle. Certains développeurs (dont moi) n'aiment pas utiliser de friend. C'est un peu comme les pointeurs, ou les variables membres mutables: à éviter tant que faire se peut. friend respecte l'encapsulation mais casse un peu les mécanismes sémantiques.

Citation:

---

Envoyé par Freem

* YATUS:
Une façon d'éviter la recompilation de Game dès qu'on ajoute un état, serait d'utiliser un conteneur de pointeurs de GameState, par exemple std::vector<GameState*> (l'utilisation de smart pointers serait plus qu'appropriée ici, mais c'est pour l'exemple) qui soit initialisé dans le constructeur.
Ainsi, la déclaration de Game n'aurait pas à dépendre aussi fortement des états ( bien que ça ne change rien pour l'implémentation ) et on évite nombre de recompilations à la moindre modification/ajout d'un état ( par exemple, on évite la recompilation de main() dans l'exemple ).

---

Effectivement, si le temps de compilation est important, alors oui c'est une bonne solution. Sinon, encore une fois, je préfère éviter l'utilisation de pointeurs.

Enfin, concernant les derniers points, il faut comprendre une chose: contrairement à la théorie, dans la vraie vie un état contient souvent des données.

Prenons l'exemple d'un jeu de plateforme: le personnage aura disons 3 états: marche, saut et attaque. On n'est pas obligé d'utiliser une machine à état pour faire ça, mais c'est une solution possible; en particulier c'est fort pratique pour gérer les animations et les transitions entre animations.

Déjà, si le jeu est multijoueur, alors utiliser des singletons pour les états n'est pas possible, puisque chaque personnage a ses propres états.
Ensuite, chaque état aura des données qui, justement, caractérise cet état. Par exemple, l'état "marche" aura besoin de données du type 'direction', 'vitesse' ou encore des informations concernant l'animation (sprite courant), ce genre de choses.

Dans d'autres situations, par exemple dans le cas de logiciels qui commandent des robots complexes (informatique industrielle), alors les états peuvent avoir beaucoup, beaucoup plus de données (je pense notamment aux données relatives aux capteurs). Et d'un point de sémantique, ça n'a pas de sens de faire remonter ces données au niveau du contexte, ni même de la super-classe State, parce que ces données sont spécifiques à chaque état. On peut encapsuler ces données dans une structure qui sera agrégée par les états concret, mais le problème reste le même: un new peut être coûteux, et surtout en terme de code (le problème de la mémoire est très rarement important).

Citation:

---

Envoyé par r0d

C'est justement ça le "cas de conscience" dont je parle. Certains développeurs (dont moi) n'aiment pas utiliser de friend. C'est un peu comme les pointeurs, ou les variables membres mutables: à éviter tant que faire se peut. friend respecte l'encapsulation mais casse un peu les mécanismes sémantiques.

---

Pareil, par contre je me demandais si passer State en class interne a Context ne resoudrai pas le probleme? Les classes internes peuvent acceder a leur class encapsulante, mais je ne sais plus si c'est vrai pour leurs derivees...

Citation:

---

Envoyé par r0d

Enfin, concernant les derniers points, il faut comprendre une chose: contrairement à la théorie, dans la vraie vie un état contient souvent des données.

Prenons l'exemple d'un jeu de plateforme: le personnage aura disons 3 états: marche, saut et attaque. On n'est pas obligé d'utiliser une machine à état pour faire ça, mais c'est une solution possible; en particulier c'est fort pratique pour gérer les animations et les transitions entre animations.

Déjà, si le jeu est multijoueur, alors utiliser des singletons pour les états n'est pas possible, puisque chaque personnage a ses propres états.
Ensuite, chaque état aura des données qui, justement, caractérise cet état. Par exemple, l'état "marche" aura besoin de données du type 'direction', 'vitesse' ou encore des informations concernant l'animation (sprite courant), ce genre de choses.

Dans d'autres situations, par exemple dans le cas de logiciels qui commandent des robots complexes (informatique industrielle), alors les états peuvent avoir beaucoup, beaucoup plus de données (je pense notamment aux données relatives aux capteurs). Et d'un point de sémantique, ça n'a pas de sens de faire remonter ces données au niveau du contexte, ni même de la super-classe State, parce que ces données sont spécifiques à chaque état. On peut encapsuler ces données dans une structure qui sera agrégée par les états concret, mais le problème reste le même: un new peut être coûteux, et surtout en terme de code (le problème de la mémoire est très rarement important).

---

Une note a propos de tout ca: la premiere fois que j'ai essaye Boost.MSM, le premier test que j'ai fais c'etait de verifier le comportement d'une FSM cree avec cette bibliotheque si je la mets dans un vector.
Je sais plus exactement pourquoi mais ca crash VC10 a la compilation...

Bref, tout ca pour dire que mon cas habituel maintenant c'est que j'ai des tas d'agents "betes" -dont le comportement peut etre represente par une FSM-, et que je veux pouvoir updater leur comportement "a la chaine" ce qui fais que la representation de l'agent et de son FSM sont dans des vector/array que je parcours d'une traite lors d'updates.

Pour souligner ce que tu disais, c'est effectivement tres courant dans les moteurs de jeux video surtout ceux bases sur des "composants" constituant les differentes entitees de jeux. Chaque entitee est definie par un agregat specifique d'instances differents types de composants, mais chacune de ces instances sont, techniquement dans des tableaux specifique a chaque type de composant. Cela permet, entre autre, de la parellelisation d'update.

Salut,

Citation:

---

Envoyé par r0d

C'est justement ça le "cas de conscience" dont je parle. Certains développeurs (dont moi) n'aiment pas utiliser de friend. C'est un peu comme les pointeurs, ou les variables membres mutables: à éviter tant que faire se peut. friend respecte l'encapsulation mais casse un peu les mécanismes sémantiques.

---

A vrai dire, j'ai du mal à être d'accord avec tes réticences (bien que je puisse les comprendre).

Quand elle est utilisée à bon escient, l'amitié est une alternative qui te permet d'éviter d'avoir à exposer certaines données ou fonctions qui, sans elles, finiraient en accessibilité publique, et seraient donc accessibles par n'importe qui (et donc... utilisées sans doute à mauvais escient à des endroits où elles ne devraient pas l'être).

Il ne faut bien sur pas en arriver à devoir déclarer dix amitiés envers une seule et même classe, mais si tu déclares une classe amie d'une autre, cela va, au contraire, améliorer grandement ton encapsulation.

Ceci dit, je peux comprendre, comme je te l'ai dit, tes réticences, dans le sens où tu pourrais estimer que cela rajoute une dépendance entre ces deux classes.

Mais il faut aussi raison garder: la dépendance sera de toutes manières présente à partir du moment où tu décideras de permettre à ton état d'accéder aux données ou aux fonctions de ton contexte ;)

@Freem >> Je suis relativement contre le fait de fournir un couple de mutateur et d'accesseur sur une donnée.

Si l'accesseur peut se justifier dans le sens où l'on peut considérer qu'il s'agit bel et bien d'un service fourni par la classe, le mutateur permet de modifier une donnée depuis "n'importe où" car il expose la donnée aussi surement que si elle était en accessibilité publique.

Etant donné que l'on peut considérer que la donnée ne devrait sans doute être modifiée qu'au travers de l'état (ou au travers d'autres actions bien spécifiques) l'amitié tend à devenir une alternative des plus valables dans le sens où elle permettra, justement, de modifier "sans contrôle excessif" une donnée du contexte au niveau de l'état, tout en évitant que cette exception ne finisse par être pratique courante dans le reste du code ;)

Tout d'abord, comme je disais, j'évite d'utiliser friend, mais cela ne veut pas dire que je ne l'utilise jamais.

Et si je n'aime pas l'utiliser, ce n'est pas pour un raison de dépendance, car effectivement, comme tu l'as dit, la dépendance est là de toutes façons.

Non, si je n'aime pas utiliser friend, c'est à cause de la sémantique du code. Prenons un exemple: une classe Car (voiture), qui a deux caractéristiques: vitesse et direction. Cette classe est conçue dans le but de se débrouiller toute seule: pour l'affichage (fonction Draw()), on lui passe le contexte et elle s'affiche "toute seule":

Code:

---

1 2 3 4 5 6 7 8 9

class Car { public: void Draw( sf::RenderWindow & window );   private: Direction direction_; double speed_; };

---

C'est en quelque sorte de la programmation par service. La classe Car rend le service qui est celui de s'afficher dans la fenêtre donnée.

Maintenant on voudrait que la voiture possède également un état courant, parmi 3 états possibles: Normal, Damaged (abimé) et InFire (en feu).
Les états Damaged et InFire ont besoin de connaître la vitesse et la direction pour afficher la fumée et les flammes de la façon la plus réaliste possible. Alors on ajoute les états et on les met en friend pour accéder à speed_ et direction_:

Code:

---

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

class Car { friend CarState; public: void Draw( sf::RenderWindow & window );   private: CarState* current_state_;   private: Direction direction_; double speed_; };   class CarState { protected: Car* owner; inline const Direction & GetCarDirection() const { return owner_->direction_; } inline const double & GetCarSpeed() const { return owner_->speed_; } };   class NormalCarState : public CarState { /* code */ }; class DamagedCarState : public CarState { /* code */ }; class InFireCarState : public CarState { /* code */ };

---

Notez que GetCarDirection et GetCarSpeed sont implémentés dans la classe de base des états afin d'être utilisables dans tous les états qui en héritent (pas besoin, ainsi, de déclarer tous les états comme amis).
Notez aussi que ce sont deux accesseurs, et que les accesseurs c'est le mal; on commence donc à s'approcher des enfers.

Ensuite, on veut que nos états puissent modifier la vitesse de la voiture. Par exemple, lorsqu'elle est en feu, alors on veut que la voiture diminue sa vitesse jusqu'à s'arrêter. Alors il faut implémenter des mutateurs dans la classe CarState! Quelle horreur!

ça va ressembler à ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10

class CarState { protected: Car* owner; inline const Direction & GetCarDirection() const { return owner_->direction_; } inline const double & GetCarSpeed() const { return owner_->speed_; }   inline void SetCarDirection( const Direction & direction ) { owner_->direction_ = direction; } inline void SetCarSpeed( const Direction & speed) { owner_->speed_ = speed; } };

---

Déjà c'est super moche, là on est aux portes des enfers. Mais si en plus, on veut gérer d'autres choses lorsqu'on modifie la vitesse de la voiture, comme par exemple envoyer des events au moteur audio, alors ça devient n'importe quoi: on voudra gérer ça dans la classe CarState, mais dès qu'on voudra changer la vitesse d'une autre façon, par exemple sur un event du controller (action du joueur par exemple), alors on est niqué! Dans les flammes de l'enfer! Et on en est arrivé là parce que - et c'est où je voulais en venir - on a pas fait attention à la sémantique: en donnant l'amitié à la classe CarState, on lui permet de s'occuper de choses dont elle n'a pas à s'occuper.

C'est une erreur classique, et pour généraliser, le problème de l'amitié c'est qu'on effectue un transfert de responsabilité, et de façon assez peu explicite, ce qui ouvre la porte à certaines fenêtres.

Citation:

---

Envoyé par r0d

Notez aussi que ce sont deux accesseurs, et que les accesseurs c'est le mal; on commence donc à s'approcher des enfers.

---

A vrai dire, les accesseurs sont surtout le mal lorsqu'ils ne correspondent pas à un service que l'on est en droit d'attendre de la part de la classe, ou lorsqu'ils nous obligent à avoir la connaissance d'un type "complexe" alors que l'on pourrait se passer de cette connaissance.

Citation:

---

Ensuite, on veut que nos états puissent modifier la vitesse de la voiture. Par exemple, lorsqu'elle est en feu, alors on veut que la voiture diminue sa vitesse jusqu'à s'arrêter. Alors il faut implémenter des mutateurs dans la classe CarState! Quelle horreur!

ça va ressembler à ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10

class CarState { protected: Car* owner; inline const Direction & GetCarDirection() const { return owner_->direction_; } inline const double & GetCarSpeed() const { return owner_->speed_; }   inline void SetCarDirection( const Direction & direction ) { owner_->direction_ = direction; } inline void SetCarSpeed( const Direction & speed) { owner_->speed_ = speed; } };

---

Déjà c'est super moche, là on est aux portes des enfers. Mais si en plus, on veut gérer d'autres choses lorsqu'on modifie la vitesse de la voiture, comme par exemple envoyer des events au moteur audio, alors ça devient n'importe quoi: on voudra gérer ça dans la classe CarState, mais dès qu'on voudra changer la vitesse d'une autre façon, par exemple sur un event du controller (action du joueur par exemple), alors on est niqué! Dans les flammes de l'enfer! Et on en est arrivé là parce que - et c'est où je voulais en venir - on a pas fait attention à la sémantique: en donnant l'amitié à la classe CarState, on lui permet de s'occuper de choses dont elle n'a pas à s'occuper.

C'est une erreur classique, et pour généraliser, le problème de l'amitié c'est qu'on effectue un transfert de responsabilité, et de façon assez peu explicite, ce qui ouvre la porte à certaines fenêtres.

---

Pour cela par contre, je ne peux forcément qu'être d'accord avec toi ;)

Citation:

---

Envoyé par r0d

Ensuite, on veut que nos états puissent modifier la vitesse de la voiture. Par exemple, lorsqu'elle est en feu, alors on veut que la voiture diminue sa vitesse jusqu'à s'arrêter. Alors il faut implémenter des mutateurs dans la classe CarState! Quelle horreur!

---

Yep. friend devrait s’hériter, ce qui permettrait de mettre les mutateurs en privé directement dans car. À ce titre, j’aime beaucoup le mécanisme d’accessibilité d’Eiffel (définition individuelle de qui peut appeler chaque méthodes, à partir d’une classe de base).

En effet, j'évite friend comme la peste aussi. Mais je préfère utiliser friend plutôt que mettre une propriété en accès public.
Il me semble évident qu'il faut réfléchir à deux fois avant d'accéder à un attribut d'une autre classe (que ce soit via friend ou un attribut public), puis supprimer ce qu'on a fait, et re réfléchir 2 fois.

Quant à l'intérêt de modifier des données du contexte en fonction de l'état, hé bien, je ne suis pas encore très à l'aise avec pattern (de la même façon et pour les mêmes raisons qu'avec le pattern visiteur en fait: accès à des données internes par un étranger), donc c'est peut-être une mauvaise idée.

Je crois que l'exemple que j'avais en tête était l'init une connexion d'un client à un serveur, ou le client doit:
1) se faire accepter et reconnaître
2) se synchroniser (et n'avoir qu'une partie des données, il est inutile et même dangereux de dire à tout le monde l'état exact et complet du jeu: si un ennemi est invisible par exemple, cela permettrait une tricherie tout ce qu'il y a de plus simple)
3) faire son boulot
4) tout en pouvant informer d'un problème de connexion
Enfin, c'est peut-être tout bêtement le mauvais dp pour cette tâche.

Citation:

---

Envoyé par koala01

@Freem >> Je suis relativement contre le fait de fournir un couple de mutateur et d'accesseur sur une donnée.

Si l'accesseur peut se justifier dans le sens où l'on peut considérer qu'il s'agit bel et bien d'un service fourni par la classe, le mutateur permet de modifier une donnée depuis "n'importe où" car il expose la donnée aussi surement que si elle était en accessibilité publique.

---

Honnêtement? Moi aussi.
Je suis d'ailleurs, et ai toujours été, contre l'idée même d'accesseurs: connaître un accesseur signifie connaître l'état interne d'une autre classe, qui n'est donc plus la seule experte.
A l'époque ou l'on a tenté de m'enseigner la POO (échec critique je dirais, même si j'ai fini par acquérir la logique plus tard) les profs disaient de tout mettre en private et de coller des accesseurs publics à chaque fois. Ou c'est ainsi que j'ai compris leurs cours, et ayant un passif C (débutant, ça ne faisait que 3 ans que je programmais après tout) je ne voyais pas l'intérêt de ces lignes de code en rab. Je n'aime toujours pas, mais pour d'autres raisons, sûrement meilleures :) .

C'était juste pour mettre en valeur le fait que l'on pouvait utiliser friend en combinaison avec un mécanisme (getter/setter dans l'exemple) pour cacher l'accès direct aux données, tout en permettant à un état d'altérer le contexte, sans coller les propriétés de ce contexte en public. C'est une solution du moins pire, si vous voulez.
Après, il y a d'autres alternatives. Mettre les états en ami un par un au cas par cas par exemple... n'est-ce pas plus lourd voire même pire? Parce que dans cette solution, il faut ajouter au contexte un ami à chaque nouvel état altérant ou simplement accédant, et en plus l'expertise se retrouve dans chaque état directement, plutôt que via l'interface fournie par l'ancêtre, qui aura été écrit en même temps que le contexte et par la même personne, qui peut donc décider ( et documenter) que seul un nombre restreint de propriétés doivent être accessibles ( lecture, écriture ou les deux ) par les états.
Et ce n'est jamais accessible par autre chose que les états, contrairement à si on avais mis en public les propriétés, donc qualifier d'infernale cette technique me semble un poil exagéré ;) éventuellement, d'apostate, ou de blasphématoire, mais pas infernale ^^

Citation:

---

Envoyé par r0d

Effectivement, si le temps de compilation est important, alors oui c'est une bonne solution. Sinon, encore une fois, je préfère éviter l'utilisation de pointeurs.

---

J'aurai été d'accord avec toi il y a 3 ans. Avant C++11. Qui plus est, il existe certains outils (genre boost::pointer_container ou un truc du genre) qui permettent de faire comme si ce n'étaient pas des pointeurs. Conteneurs polymorphiques en somme.
Et donc, pas de pointeurs (apparents du moins), et pas de recompilation. Bon, certes, cet outil à un coût au runtime, à cause des dynamic_cast internes de mémoire... mais bon, ça s'optimise quand ça deviens un problème ça.

Citation:

---

Envoyé par r0d

Enfin, concernant les derniers points, il faut comprendre une chose: contrairement à la théorie, dans la vraie vie un état contient souvent des données.
<snip>
Déjà, si le jeu est multijoueur, alors utiliser des singletons pour les états n'est pas possible, puisque chaque personnage a ses propres états.
<snip>
alors les états peuvent avoir beaucoup, beaucoup plus de données (je pense notamment aux données relatives aux capteurs)

---

Tout à fait d'accord. Si l'état est une donnée en lui-même, il n'en reste pas moins une donnée composée.
Mais pour reprendre ton exemple de jeu, ces états altèrent tous une propriété "position" j'imagine, qui elle appartient au personnage (contexte).

Pour le fait qu'un état puisse contenir beaucoup de données, ça ne me choque pas. Cependant, il existe d'autres DP pour les problèmes de mémoire / temps de construction. En vrac:
_ factory
_ prototype
_ builder
_ flywieght
Et peut-être même d'autres. Combiner les pattern entre eux ne me pose absolument aucun souci, je dirai même que certains semblent faits pour ça. Je peux me planter, mais dans le cas de la multitude de données, ça ressemble à vue de nez (mais sans contexte exact, impossible de le dire) à un usage de builder.

Toujours est-il que le but d'utiliser les constructeurs et opérateurs de cast était surtout pour fournir un moyen simple d'offrir les transitions en exploitant les capacités du C++.
Si je reprend l'exemple du jeu:
on passe d'un état "marche" à "statique" => m_state = StaticState( m_state );
on passe d'un état "saute" à "statique" => m_state = StaticState( m_state );

0 changement donc. Autre point intéressant: pas besoin de vérifier nous-même la possibilité de passer d'un état à l'autre: le compilateur le fait nous même: si le bon constructeur ou operateur de cast manque, alors ça ne compilera juste pas.
C'est juste une possibilité supplémentaire

(note a moi-même, il va falloir que je pense a activer le suivi auto par mail, vu que je passe beaucoup moins souvent qu'avant ... )