State machine representation

Question

I want to implement the GUI as a state machine. I think there are some benefits and some drawbacks of doing this, but this is not the topic of this questions.

After some reading about this I found several ways of modeling a state machine in C++ and I stuck on 2, but I don't know what method may fit better for GUI modeling.

1. Represent the State Machine as a list of states with following methods:

   • OnEvent(...);
   • OnEnterState(...);
   • OnExitState(...);

   From StateMachine::OnEvent(...) I forward the event to CurrentState::OnEvent(...) and here the decision to make a transition or not is made. On transition I call CurrentState::OnExitState(...), NewState::OnEnterState() and CurrentState = NewState;

   With this approach the state will be tightly coupled with actions, but State might get complicated when from one state I can go to multiple states and I have to take different actions for different transitions.

2. Represent the state machine as list of transitions with following properties:

   • InitialState
   • FinalState
   • OnEvent(...)
   • DoTransition(...)

   From StateMachine::OnEvent(...) I forward the event to all transitions where InitialState has same value as CurrentState in the state machine. If the transition condition is met the loop is stopped, DoTransition method is called and CurrentState set to Transition::FinalState.

   With this approach Transition will be very simple, but the number of transition count might get very high. Also it will become harder to track what actions will be done when one state receives an event.

What approach do you think is better for GUI modeling. Do you know other representations that may be better for my problem?

Answer 1

I don't know if this is the kind of answer you are expecting, but I use to deal with such state machines in a straightforward way.

Use a state variable of an enumerated type (the possible states). In every event handler of the GUI, test the state value, for instance using a switch statement. Do whatever processing there needs to be accordingly and set the next value of the state.

Lightweight and flexible. Keeping the code regular makes it readable and "formal".