Fragen zum State Pattern
-
Hallo, ich habe einige Fragen zum State Pattern. Ich muss einen Getränkeautomaten umsetzen, hierfür will ich eine 3-Schichten Architekur verwenden. In der Logik Schicht will ich ein State Pattern verwenden http://www.dofactory.com/Patterns/PatternState.aspx. Wenn ich in ein anderen Zustand wechseln will, muss ich doch in dem aktuellen Zustand den State ändern oder?
Beispiel: StateA -> StateB
Eine Automat hat mehrere Transitionen, diese werden im Interface State definiert, d.h. doch das auch in jedem Zustand diese Transition behandelt werden muss oder?!?!
-
kernel64 schrieb:
Wenn ich in ein anderen Zustand wechseln will, muss ich doch in dem aktuellen Zustand den State ändern oder?
Eher im Context, so wie es in deinem Link genannt wird.
-
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 dasZustandB
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: