As developers, we're often in the situation where we need to keep track of an object's state.
For example, your user system might require users to activate their accounts by clicking a link on
an email, and you might also offer users the ability to deactivate their accounts rather than merely deleting them.
To do this, you would typically have an enum field called something like "status" with the fields:
and that's great. But what if you need to do something when a user activates their account?
You need to store the user's current status after find, then check if it has changed, then, finally do your magic,
that could get complicated if you have other status fields.
And also, what if you have business logic that only applies when the user is in a certain state?
After all, an active user should not be able to activate their account a second time, just as a deactivated user should
not be able to deactivate their account a second time. Again, when a user can have a lot of different states,
this can become code spaghetti pretty quickly.
This is where the state machine comes in.
The state machine keeps track of the user's state, and manages the transitions from one state to another.
A state can encapsulate logic that only applies when the state machine is in that state, and also provides
events that are raised when the state is transitioned from and to.
When the state machine is in a certain state, the methods and properties declared on that state become available to the state machine.
This means that in the user scenario, we could implement:
This keeps our model code clean, separates the business logic into easily testable chunks
and ensures that a user cannot accidentally be activated or deactivated more than once because the relevant methods
are simply not available when the machine isn't in the right state.
So when a user clicks their activation email, we can transition to the active state and send them an welcome email,
safe in the knowledge that they won't get multiple welcome emails if they happen to click the activation link more than once.
Often we need to check what state can become active after current. We can override
beforeExit or beforeEnter methods of AState as described.
This approach is very flexible but it may make you crazy if you should describe a big graph of states.
In this case you can free your time by setting AStateMachine.checkTransitionMap to TRUE
and specifying AState.transitsTo attribute for all states. This attribute describes which states can
be reached from current. See example below.
So lets see which states can be reached.
Here we saw availableStates attribute ( or getAvailableStates() ). This is useful
method when we want provide ability to switch state by user in an UI.