I'd have a 'high level' State Machine
class which controls the entry/running/exit of each state (where states could be things like 'filling', 'washing', 'rinse', 'emptying', 'spin dry', etc)
Draw up a State Transition Diagram of all the states you need, including (for each state)
- what requirements there are before you enter the state (entry conditions)
- what needs to happen when you enter the state (entry actions)
- what happens during the state (the task itself)
- what requirements there are before you can leave the state (exit conditions)
- what happens when you exit the state (exit actions)
You may or may not need the entry/exit conditions (e.g. you can force the conditions with an entry/exit action in some cases). For safety reasons though, some conditions can be good (e.g. exiting from a 'standby' state or entry into a 'dangerous' state like spin dry)
You also create Transitions
, which define the links between states. A transition has
- a 'from' state
- a 'to' state
- transition conditions (can the transition happen?
- transition actions (what needs to happen when you transition)
Again, you may not need all of these, and many transitions will have only the 'from' and 'to' states specified.
In both cases, try to keep each State
and Transition
as simple as it needs to be (try to put the conditions/actions where they make the most sense, obviously there's potential double-up of these to be defined in a State
and a Transition
because of the generic design)
It should be pretty obvious at this point that you can make a fairly generic State
class which includes abstract/overloadable functions for all of these things, and likewise for the Transition
class. The State Machine
class can call each of these member functions as required, based on the transitions requested of it.
If you make it especially generic, then the States
and Transitions
can be registered with the State Machine
at construction time, or you might just code the State Machine
to contain them all.
You can then request transitions, either from within states (i.e. a particular state can know when it has ended, and know which state to go to next) or you could have an external class which controls the state transitions (each state is then very simple, purely taking care of its own actions, and the external class decides the order and timing of transitions).
In my experience with these things, it's a good idea to separate the high level logic of deliberate order/timing of each action and the low level logic of reaction to some hardware event (e.g. transition out of the 'filling' state when the water level is reached).
It's a really generic design though, and you can achieve exactly the same functionality a bunch of different ways -- there's rarely a single right way of doing things...