This model is much like this, basically don't need to explain, here will take an example to talk about it.
Just lifting a classic subway cointer. If it is locked, I want to pass the warning, and the coin will be unlocked; if it turns out, then the coin will thank you, and then re-lock.
If the design program mimes this door, you can use IF / ELSE or SWITCH / CASE:
IF (state == Locked)
IF (Event == COIN)
unlock ()
State = unlocked
Else IF (Event == Pass)
Alert ()
Else IF (state == unlocked)
IF (Event == COIN)
Thanks ()
Else IF (Event == Pass)
Lock ()
State = LOCKED
The shortcomings of this implementation, I don't say much, it is difficult to make a good response to future extensions, logical concentration, easy to make mistakes.
Without this, we can also write status / event / action / action to a state migration table.
Transitions = array of transition
Transitions.add (Locked, Coin, Unlock, Unlocked)
Transitions.add (Locked, Pass, Alert, Locked)
Transitions.add (unlocked, coin, thanks, unlocked)
Transitions.add (Unlocked, Pass, Lock, Locked)
Call in the function
For (i = 0; i { Transition = transitions.at (i); IF (state == transition.state && event == transition.event) { Transition.action.execute () State = transition.newstate } } This is actually good, each time you modified, as long as you maintain the migration table, the price is speed, traversal, and if there are many status, you are annoying.
