9/1/13

Yahoo! Search

architecture - Finite State Machine Pattern - The One True Pattern? - Stack Overflow

Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

Tell me more

Finite State Machine Pattern - The One True Pattern?

Could all Code ever written be improved by applying the State Machine Pattern? I was working on a project that was a mass of horrendous awful, buggy, broken spaghetti code. I copied Martin Fowler's example State Machine code from this blog and transformed the whole heap of crap into a series of statements. Literally just a list of States, Events, Transitions and Commands. I can't believe the transformation. The code is now clean, and works. Of course i was aware of State Machines before and have even implemented them but in the Martin Fowler example the separation of model/configuration is amazing. This makes me think that almost everything i've ever done could have benefitted in some way from this approach. I want this functionality in every language i use. Maybe this should even be a language level feature. Anyone think this is wrong? Or anyone have a similar experience with a different pattern?
design-patterns architecture state-machines

edited Feb 16 '11 at 15:50

asked Feb 16 '11 at 15:33 hooleyhoop 6,052 2 17 35

I like state machines a lot for many embedded programming problems.. I do find that the pattern tends to either explode (huge increase in states) or fall apart (people violating the pattern) when special cases, requirements changes, etc. come into the picture, especially when the changes are made by less experienced/competent developers. Some situations (dynamically specified numbers of retries for example) require care to implement properly in a FSM. Splat Feb 20 '11 at 17:19 beware of the Golden Hammer antipattern! sourcemaking.com/antipatterns/golden-hammer swinefeaster Nov 5 '12 at 21:53

2 Answers
Finite state machines (FSM's) and more specifically domain specific languages (DSL's) make it easier to match a problem to one specific solution domain, by describing the solution in a specialised language. The limitations of the State Machine pattern is that it itself constitutes a programming language, but one for which you have to write your own execution, testing and debugging tools; and one which any maintainer has to learn. You have moved the complexity of your code into a complex FSM configuration. Occasionally, this is useful, but certainly not universally. And since any von Neumann computer is itself a FSM, then certainly any program can be recast in this fashion.
answered Feb 16 '11 at 15:39 Pontus Gagge 12k 19 36 I think i'm going to have to read the Fowler book. I never thought of the State machine as a DSL. I see how it has moved the complexity elsewhere but for me that's the bonus. It's factored out from seemingly unrelated

stackoverflow.com/questions/5018391/finite-state-machine-pattern-the-one-true-pattern

1/3

9/1/13

has moved the complexity elsewhere but for me that's the bonus. It's factored out from seemingly unrelated code (in my case, say, a media player, an accounting app and a social website) a core of reusable, tested code. hooleyhoop Feb 17 '11 at 15:53

architecture - Finite State Machine Pattern - The One True Pattern? - Stack Overflow

Spaghetti code is never the right answer. Patterns are good at cleaning up spaghetti code, but just having a well thought out design can achieve the same thing. With respect to the state-machine question: I personally find them to be very useful. For a public facing app I created, I refactored to use a state-chart (which I think is the same thing as the state-machine) and noticed the benefits you mentioned. It is a really useful abstraction, because it allows you to separate the concern of handling events out into a separate component. With this, bugs go away because the statechart implicitly knows what a user can do where, and since the events are only handled in the right place, you can't really perform an invalid action. Also, using the state-chart allowed me to simplify the code because I could pull all the event handling code out of where it was and put it where it in one place where it was supposed to be -- in other words, other components weren't complicated by also having event handlers on them. A picture is worth a thousand works -- Here is the design I came up with:

With this, anyone who looks at it knows exactly how the app behaves at a high level. Its hard to break this, because like I said, you can't get to an invalid state because the event handlers control exactly where you can go; if you can get to an invalid state, its an implementation bug that is easily fixed. Also, the code cleansing benefits are enormous. For example, with the state chart, whenever I enter any paused state, I can do things like stop the clock, put a mask on the board, etc. Its a few lines of code in one place -- because when i enter a substate of paused the chart goes thru the parent state first. without the statechart, I would have to do that code everywhere an event was handled. I don't know if it needs to be a language level feature, but having a well implemented framework is nice.
edited Feb 16 '11 at 15:56 answered Feb 16 '11 at 15:42 hvgotcodes 45.8k 6 59 118

Thankyou both for these great answers. I guess reading about a design pattern is one thing but actually grasping how incredibly useful it is is another. hooleyhoop Feb 17 '11 at 15:47

stackoverflow.com/questions/5018391/finite-state-machine-pattern-the-one-true-pattern

2/3

9/1/13

grasping how incredibly useful it is is another. hooleyhoop Feb 17 '11 at 15:47

architecture - Finite State Machine Pattern - The One True Pattern? - Stack Overflow

Not the answer you're looking for? Browse other questions tagged design-patterns
architecture state-machines or ask your own question.

stackoverflow.com/questions/5018391/finite-state-machine-pattern-the-one-true-pattern

3/3