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]

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