Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
Understood. Getting an example of the right level is extremely difficult and I think overall you've done an excellent job in the tutorial. Of course the interesting design question is, at one point does the obvious increase in code complexity make using the library 'worth using'?
When the obvious increase in code complexity is smaller than the obvious decrease in code complexity? I really need to ask - an obvious increase in complexity over what? I have seen some truly complex code arise from *not* using an fsm framework in some form or another. My attempt at a heuristic is that one should consider using the fsm libary when: 1) There are more than a handful of transitions per state 2) There are more than a handful of states 3) The state space is naturally hierarchical 4) There is substantial context associated with (groups of) states If you have only (1) or (2), it is likely that the problem doesn't warrant using boost fsm. If you have (1) and (2) it is worth at least thinking about using boost fsm, with substantial size or the presence of either of the other 2 features being enough to make it pretty much an immediate choice.
So the other general design question is -- when is it better to but the variables asoociated with the machine in a state class versus pushing them up to the machine?
Innermost (leaf) states are usually empty, outer states are really a sort of sub-machine and it is just a scoping issue - if the variable scope is clearly tied to the lifetime of the outer state/sub-machine, put it there. Transition functions then naturally are placed in the same state/context as the variables they manipulate.
Again there may be no answer here, but maybe someone that has implemented real code using fsm would have a design heuristic...
I have seen substantial reductions in code complexity arise out of using the fsm libary in a refactoring of some existing code. The result is also much easier to modify/maintain. This last point is particularly important if the fsm is not well specified to start with and/or may need to be modified in reaction to changes in requirements. Using boost fsm an iterative/exploratory design approach works fine. In many ways this is less painful than if there were a code generator. I'd actually prefer a diagram/documentation generator. I'd be interested to hear other views on heuristics too. I haven't applied my suggestion above to a sufficient variety of problems to be able to state it with any authority. Anotehr heuristic that I see emerging is that it where an number of little fsms turn up in a program it is worth at least considering if more of the program cant be described as an fsm at a design/modeling level. With the right tools this can result in something that can be far more easily coded/validated/tested than by taking a more fragmented approach. Regards Darryl Green.