Fragen zum State Pattern



  • Eben nicht, in jedem Zustand wird der Status vom Context geändert, hier SilverState:

    private void StateChangeCheck()
    {
        if (balance < lowerLimit)
        {
           account.State = new RedState(this);
        }
    
        else if (balance > upperLimit)
        {
            account.State = new GoldState(this);
    
         }
    }
    


  • Die States definieren das Verhalten. Ergo aenderst du die States in den States.

    Der Kontext hat ja keine Ahnung von den einzelnen konkreten States...

    Die States haben aber eine gemeinsame Basisklasse wo gemeinsames verhalten definiert werden kann.

    Aber um ehrlich zu sein: ich hab keine Ahnung was die eigentliche Frage ist...



  • Alle Möglichen Ereignisse werden doch in der Basis State definiert, z.B.:

    ProdukAuswahl()
    GeldRückgabe()
    ...

    Diese können doch in jedem Zustand aufgerufen werden, meine Frage war ob diese Ereignisse auch in den einzelnen Zuständen aufgerufen werden?

    ZustandA
    ProdukAuswahl()
    - mache das

    ZustandB
    ProdukAuswahl()
    - mache nix



  • kernel64 schrieb:

    Diese können doch in jedem Zustand aufgerufen werden, meine Frage war ob diese Ereignisse auch in den einzelnen Zuständen aufgerufen werden?

    ereignisse kommen normalerweise von aussen in die state machine und sorgen dafür, dass sich ihr zustand ändert (oder nicht). genau genommen sollte ein zustandsautomat selbst keine ereignisse direkt auslösen. machbar ist natürlich alles.
    🙂



  • JA klar werden die von außen ausgelöst z.b. in der GUI, aber wenn ich im Zustand Produktasugabe bin, kann ich als Mensch im Automaten auch auf die Reset Taste drücken. Also dieses Verhalten muss auch beachtet werden, das meinte ich damit.



  • kernel64 schrieb:

    JA klar werden die von außen ausgelöst z.b. in der GUI, aber wenn ich im Zustand Produktasugabe bin, kann ich als Mensch im Automaten auch auf die Reset Taste drücken. Also dieses Verhalten muss auch beachtet werden, das meinte ich damit.

    na, dann mal dir doch deine state machine auf, mit allen zuständen, übergängen usw. dann haste ein schönes bildchen, aus dem du ablesen kannst, welches ereignis welche auswirkungen hat. du bist doch hier der uml-freak.
    🙂



  • Shade Of Mine schrieb:

    Aber um ehrlich zu sein: ich hab keine Ahnung was die eigentliche Frage ist...

    Ich auch, aber die Antwort würde ich trotzdem gern wissen.



  • kernel64 schrieb:

    JA klar werden die von außen ausgelöst z.b. in der GUI, aber wenn ich im Zustand Produktasugabe bin, kann ich als Mensch im Automaten auch auf die Reset Taste drücken. Also dieses Verhalten muss auch beachtet werden, das meinte ich damit.

    Deshalb erben die States ja von einer gemeinsamen Basisklasse.

    Denn nimm als Beispiel einen "zurueck" Button. Der macht je nach State etwas anderes. Dann gibt es natuerlich auch Buttons die immer das selbe machen, zB reset oder power off.

    Deshalb muss Power Off natuerlich in jedem Zustand funktionieren (aber uU hast du auch einen Zustand wo Power Off nicht geht, zB wenn du gerade ein FirmWare update einspielst...). Und fuer solche Ereignisse gibt es eben eine gemeinsame Basisklasse die das gemeinsame Verhalten definiert.

    Aber mir fehlt schon wieder eine Frage.

    Aber jeder State muss auf gewisse Ereignisse reagieren koennen und auf manche Ereignisse reagieren alle States gleich.

    Und bitte, stell einfach eine konkrete Frage...



  • ich stell jetzt einfach mal ne frage dazu, die er vielleicht auch wissen wollte.

    class StateA : public State {...}  
      class StateB : public State {...}
    
      class Machine{
        State* currentState;
      }
    

    Wer setzt den neuen currentState, wenn der sich ändert? Der state der gearde gesetzt ist? Die Machine? Wer anders?
    Oder ist der Aufbau ganz falsch?



  • So wie ich es verstanden habe in den einzelnen Zuständen, z.b. StataA in StateB

    Siehe hier das Beispiel:

    http://www.dofactory.com/Patterns/PatternState.aspx


Anmelden zum Antworten