1. #1
    r0d
    r0d est déconnecté
    Expert éminent

    Profil pro
    Inscrit en
    août 2004
    Messages
    4 229
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2004
    Messages : 4 229
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    1

    Par défaut 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.

  2. #2
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2008
    Messages : 1 505
    Points : 2 791
    Points
    2 791

    Par défaut

    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 .

  3. #3
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 13 481
    Points
    13 481

    Par défaut

    Citation Envoyé par white_tentacle Voir le message
    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.

  4. #4
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    21
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 21
    Points : 19
    Points
    19

    Par défaut Encore

    Miam miam j'en veux d'autres

    Merci

  5. #5
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2008
    Messages : 1 505
    Points : 2 791
    Points
    2 791

    Par défaut

    Citation Envoyé par 3DArchi Voir le message
    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).

  6. #6
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 13 481
    Points
    13 481

    Par défaut

    Citation Envoyé par white_tentacle Voir le message
    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 Voir le message
    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 Voir le message
    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.

  7. #7
    r0d
    r0d est déconnecté
    Expert éminent

    Profil pro
    Inscrit en
    août 2004
    Messages
    4 229
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2004
    Messages : 4 229
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    1

    Par défaut

    @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

  8. #8
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : France

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 580
    Points : 2 202
    Points
    2 202

    Par défaut

    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.
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  9. #9
    r0d
    r0d est déconnecté
    Expert éminent

    Profil pro
    Inscrit en
    août 2004
    Messages
    4 229
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2004
    Messages : 4 229
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Goten Voir le message
    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

  10. #10
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : France

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 580
    Points : 2 202
    Points
    2 202

    Par défaut

    Ah ben voilà, maintenant y'a la coloration syntaxique partout .
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  11. #11
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 897
    Points : 7 396
    Points
    7 396

    Par défaut

    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

  12. #12
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    26 740
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 26 740
    Points : 39 180
    Points
    39 180

    Par défaut

    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"...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  13. #13
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2008
    Messages : 1 505
    Points : 2 791
    Points
    2 791

    Par défaut

    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.

  14. #14
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    26 740
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 26 740
    Points : 39 180
    Points
    39 180

    Par défaut

    Citation Envoyé par white_tentacle Voir le message
    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.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  15. #15
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 13 481
    Points
    13 481

    Par défaut

    Citation Envoyé par Médinoc Voir le message
    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

  16. #16
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 897
    Points : 7 396
    Points
    7 396

    Par défaut

    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.

  17. #17
    Membre confirmé
    Avatar de Mindiell
    Profil pro
    Inscrit en
    juin 2006
    Messages
    735
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 735
    Points : 543
    Points
    543

    Par défaut

    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 : 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.
    Mindiell
    "Souvent, femme barrit" - Elephant man

  18. #18
    r0d
    r0d est déconnecté
    Expert éminent

    Profil pro
    Inscrit en
    août 2004
    Messages
    4 229
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2004
    Messages : 4 229
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Mindiell Voir le message
    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.

  19. #19
    Membre confirmé
    Avatar de Mindiell
    Profil pro
    Inscrit en
    juin 2006
    Messages
    735
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 735
    Points : 543
    Points
    543

    Par défaut

    Citation Envoyé par r0d Voir le message
    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 Voir le message
    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
    Mindiell
    "Souvent, femme barrit" - Elephant man

  20. #20
    r0d
    r0d est déconnecté
    Expert éminent

    Profil pro
    Inscrit en
    août 2004
    Messages
    4 229
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2004
    Messages : 4 229
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Mindiell Voir le message
    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.

Discussions similaires

  1. Cas d'étude : Java et fuite mémoire
    Par Bobak42 dans le forum Langage
    Réponses: 8
    Dernier message: 04/09/2012, 14h55
  2. [conception] pattern state
    Par r0d dans le forum C++
    Réponses: 21
    Dernier message: 28/09/2009, 13h44
  3. Combinaison de plusieurs etats avec le pattern State
    Par papaetoo dans le forum Design Patterns
    Réponses: 0
    Dernier message: 18/08/2009, 11h16
  4. [DESIGN J2ME] Utilisation du pattern STATE ?
    Par BerBiX dans le forum Java ME
    Réponses: 0
    Dernier message: 04/12/2008, 15h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo