Discussion :

[r0d]

Bonjour,

voilà, je vois partout le pattern state implémenté ainsi:

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
class AbstractState {
public:
   virtual void DoSomething() = 0;
};
 
class ConcreteState1 : public AbstractState {
public:
   void DoSomething() { /* implémentation */ }
};
 
class ConcreteState2 : public AbstractState {
public:
   void DoSomething() { /* implémentation */ }
};
 
class MyObject {
private:
   AbstractState * m_state;
 
public:
   void ChangeState( AbstractState * newState ) { 
	   delete m_state; 
	   m_state = newState; 
   }
 
   void DoSomething() { m_state->DoSomething(); }
};

Seulement, dans certains cas cette façon de faire ne me convient pas, à cause du fait que quand on change d'état (fonction ChangeState dans mon exemple), il faut allouer un nouvel état et désallouer l'ancien. C'est un cas que j'ai rencontré récemment qui m'a fait penser à cela: une classe qui change souvent d'état, et dont les états possèdent des données => beaucoup d'allocation/désallocations qui, de plus, sont coûteuses.

Du coup, j'ai modifié le pattern comme ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// les classes AbstractState et ConcreteStateN ne changent pas
 
class MyObject {
private:
	AbstractState * m_state;
	ConcreteState1 m_state1;
	ConcreteState2 m_state2;
 
public:
	void GoToState1() { m_state = &m_state1; }
	void GoToState2() { m_state = &m_state2; }
 
	void DoSomething() { m_state->DoSomething(); }
};

Seulement, je n'ai vu cette implémentation nulle part. Et pourtant je lis beaucoup de code ces derniers temps. Je me demande donc s'il n'y aurait pas un problème que je n'ai pas vu et qui fait ce ma méthode est très mauvaise.

Voilà, donc c'est pour savoir: qu'en pensez-vous?

[screetch]

Il n'y a aucun problème avec ca et c'est comme ca que chacun devrait faire a mon avis =)
[EDIT] parler sans reflechir c'est mal... ca consomme plus de mémoire comme ca.

[white_tentacle]

Je ne connais pas cette façon de faire. Quand j'ai besoin d'une machine à état, j'en suis resté à la bonne vieille méthode avec une matrice d'états/transitions (sauf si le nombre d'états devient trop grand, auquel cas la matrice se transforme en fonction avec switch et if imbriqués).

J'imagine que le bénéfice de coder comme ça, c'est que tu peux rajouter des états sans toucher au code de ta classe MyObject (je n'en vois pas d'autres, et je vois plutôt plein d'inconvénients). Là, en mettant des membres dans ta classe, tu perds ce bénéfice. Du coup, autant revenir à la matrice d'états/transitions

[3DArchi]

En cherchant un peu sur le net, j'ai trouvé quelques conseils sur le pattern state qui peuvent répondre en partie à ta question :
1/ Un état ne devrait pas contenir de variables membres : seul le comportement change,
2/ Les états devraient être des singletons (en cohérence avec précédent) : ce qui évite ces allocations/destructions répétitives.

Dans ton exemple, le problème que je vois, c'est que dès que tu auras un certaine nombre d'état tu vas être tenté de refaire un switch pour positionner ton état courant...

[poukill]

Quand tu instancies MyObject, il faut que tu initialises tous les états. Après j'ai envie de dire, ça dépend combien tu as d'états et surtout est-ce que tu vas tous les "utiliser" plusieurs fois (plusieurs boucles en fait)?
Il faut quand même t'assurer que c'est moins coûteux comme ça...

Si c'est pour tourner "longtemps", alors oui dans ton implémentation tu vas consommer plus de mémoire, mais tu iras plus vite!

[Alp]

A part à rendre ça un peu plus générique, je pense que c'est pas mal

[screetch]

au pire du pire, avec une tonne de méta prog et une lisibilité réduite, tu peux avoir un buffer contenant assez de place pour le plus gros des états et faire un placement new.
tes états contiennent ils des variables ?

[r0d]

Ben en fait je parlais du cas général.

Donc si je fais une synthèse de ce qui a été dit:
avantages de cette méthode:
- cette méthode permet de gagner en rapidité d'exécution dans le cas où les états continennent des données (même si c'est déconseillé, ça peut être pratique).

désavantages de cette méthode:
- si on ajoute un état, on doit rajouter une fonction membre + une variable membre (le nouvel état) et son initialisation à la construction de l'objet.
- si on a beaucoup d'état, le code peut devenir très lourd

conclusion: bien quand on a pas beaucoup d'états.

Êtes-vous d'accord?

[screetch]

Si tu as beaucoup de ces machines a état tu risques de consommer beaucoup plus de mémoire. tes états pèsent tous au moins 4 octets (la table de méthodes virtuelles)

[white_tentacle]

J'ai vraiment du mal avec cette idée de mettre des variables dans une classe état.

L'état d'une machine à état, c'est l'union de la valeur de tous ses membres. Autrement dit, tout ce qui caractérise l'état de la machine, doit être dans la classe machine.

Sinon, je vois une grosse différence sémantique entre ce que tu fais et l'implémentation initiale :

Code :

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

1
2
3
4
void ChangeState( AbstractState * newState ) { 
           delete m_state; 
           m_state = newState; 
   }

m_state est à priori un état nouvellement créé (je vois mal comment faire autrement).

Tandis que :

Code :

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

 void GoToState1() { m_state = &m_state1; }

m_state est un ancien état, qu'on ressuscite, mais donc, avec ses anciens membres.

Ce qui fait que l'état de ta machine est très largement complexifié, puisque l'état actuel est aussi dépendant de ton historique, et d'états non courant.

Honnêtement, je ne vois pas comment on peut faire un minimum de preuve de fonctionnement (ce qui est quand même l'intérêt d'une machine à états) là dessus.

[r0d]

J'ai vraiment du mal avec cette idée de mettre des variables dans une classe état.

L'idée du pattern state c'est de déléguer des fonction à la classe état.

Prenons un exemple: ma classe Objet a une fonction LogState(); qui doit écrire de façon "humainement lisible" son état courant dans un logger. Et bien la classe State aura besoin d'une instance, ou d'un lien quelconque (référence, pointeur, que sais-je encore) vers le logger en question. On aura donc bien besoin d'une variable pour cela.

Honnêtement, je ne vois pas comment on peut faire un minimum de preuve de fonctionnement (ce qui est quand même l'intérêt d'une machine à états) là dessus.

En faisant comme ceci par exemple:

Code :

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

1
2
3
4
5
 void GoToState1() 
{ 
   m_state = &m_state1; 
   m_state->Init();
}

[3DArchi]

L'idée du pattern state c'est de déléguer des fonction à la classe état.

Prenons un exemple: ma classe Objet a une fonction LogState(); qui doit écrire de façon "humainement lisible" son état courant dans un logger. Et bien la classe State aura besoin d'une instance, ou d'un lien quelconque (référence, pointeur, que sais-je encore) vers le logger en question. On aura donc bien besoin d'une variable pour cela.

Une std::string ne possède pas une référence vers un flux pour écrire sa valeur... Le principe est le même ici. Ton état doit pouvoir se logger dans un logger qui lui est fourni.
En fait, à chaque état, ce que tu change, ce sont les comportements et pas les données qui caractérisent ton état. C'est pourquoi les variables dans les états c'est déroutant.

En faisant comme ceci par exemple:

Code :

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

1
2
3
4
5
 void GoToState1() 
{ 
   m_state = &m_state1; 
   m_state->Init();
}

En réalité, tu devrais plutôt appelé explicitement le destructeur et faire un placement new. Mais, mon sentiment est que ça devient de la bidouille.

[r0d]

Une std::string ne possède pas une référence vers un flux pour écrire sa valeur... Le principe est le même ici. Ton état doit pouvoir se logger dans un logger qui lui est fourni.
En fait, à chaque état, ce que tu change, ce sont les comportements et pas les données qui caractérisent ton état. C'est pourquoi les variables dans les états c'est déroutant.


En réalité, tu devrais plutôt appelé explicitement le destructeur et faire un placement new. Mais, mon sentiment est que ça devient de la bidouille.

Ok si tu veux. C'était un mauvais exemple. Mais il y a des cas où c'est vraiment pratique. Peut-être évitable, mais pratique. Par exemple une machine de vente de boissons: quand elle sera en état "rendre la monnaie", il y aura plein de trucs qu'elle devra savoir dont elle n'aura pas besoin dans l'état "encaisser", comme par exemple la monnaie qu'elle a en réserve.

En réalité, tu devrais plutôt appelé explicitement le destructeur et faire un placement new. Mais, mon sentiment est que ça devient de la bidouille.

C'est jsutement ce que je cherche à éviter: appeler le destructeur (et donc le constructeur après).

[3DArchi]

C'est jsutement ce que je cherche à éviter: appeler le destructeur (et donc le constructeur après).

Soit Init fait la même chose que le destructeur et le constructeur, soit il ne fait pas la même chose. Dans ce dernier cas, cela veut dire que ton état conserve une 'mémoire', donc ce n'est plus tout à fait le même état...

[r0d]

Il peut faire la même chose sans réallouer. Juste initialiser les variables membres. En plus, ainsi on peut se permettre de n'initialiser que celles qui ont besoin de l'être, c'est toujours ça de pris.

[3DArchi]

L'appel explicite au destructeur suivi du placement new ne fait pas d'allocation/libération mais se contente ... d'appeler le destructeur puis le constructeur.

[r0d]

En cherchant un peu sur le net, j'ai trouvé quelques conseils sur le pattern state qui peuvent répondre en partie à ta question :
1/ Un état ne devrait pas contenir de variables membres : seul le comportement change,
2/ Les états devraient être des singletons (en cohérence avec précédent) : ce qui évite ces allocations/destructions répétitives.

Yop,

tu saurais retrouver l'endroit où tu as lu ça? J'ai pas mal cherché mais je ne trouve rien de tel :/

[3DArchi]

Yop,

tu saurais retrouver l'endroit où tu as lu ça? J'ai pas mal cherché mais je ne trouve rien de tel :/

Non
Sinon, il y a le tutoriel sur le pattern Etat de Pierre Caboche

[r0d]

okay merci

[yan]

Salut,
Ce qu'on fait Qt est assez sympa:
http://qt.developpez.com/doc/4.6-sna...temachine-api/

Ce que j'aime bien :
* on peut éviter de faire une classe pour chaque état
* on peut tous modifier dynamiquement et utiliser SCXML
* l'utilisation du sytème de signal/slot qui permet de ne pas avoir de fonction DoSomething dans la classe états et qui permet de modifier dynamiquement le fonctionnement.

Boost a sûrement quelque chose de similaire.