What is the proper way to use QStateMachine - design issue.

[33333]

Hi all,

This is a somewhat academic and maybe newb question but Id like to do things properly and Ive been thinking about this issues for a couple of days. I'm reimplementing some control software that and have decided to use some state machine frame work to do this (since it was really ugly without it). Naturally Ill use QStateMachine. But there is two design alternatives and I'm struggling to deiced which to use. In both basically we have a facade class that acts as interface to the GUI etc, with a composite QStateMachine inside it. The state of objects of this class is driven by pokes from the GUI and hardware it provides an interface to.

Alternative 1: All the core logic relevant to each state is implemented in methods of facade class/object. Simple transitions between states can be programmed to occur from external signals, but facade object methods implement complicated logic deciding when to transition, then poke the state machine with an event or signal to cause transition. On entry/exit from states signals connected to the facade object will be reconnected as appropriate for the state. This alternative makes it easy to share data between state logic, as methods implementing it share the same object context.

Alternative 2: All states extend QState, reimplementing onEntry()/onExit() and whatever else, and the logic relevant to each state is implemented in the QStates themselves. This nicely partitions the logic relevant to each state but makes it harder to share data. In this alternative you can also emit QState::finished() to affect a transition which is nice (there no external QState::finish() function to poke a QState from the outside as you might like to do in alternative 1).

I guess Im asking, as a newb does it depend, and what is you advice/experience with implementing complicated state machines? I think it probably depends and Alternative 1 is OK for simple things. Still would appreciate advice.

Thanks.

[StrikeByte]

In my opinion alternative 2 is the best way to go. If you only want to change one state you can replace only one class without digging into a large set of code with different states.
To make it easyer to communicate between different states you can write an interface class ontop of the QState and on top of that you can write the class implementation.
To bind all the states together you can write a controller class or something like it