9/1/13 architecture - Finite State Machine Pattern - The One True Pattern? - Stack Overflow

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

Tell me more ×

hooleyhoop

6,052 2 17 35

2 Answers

Pontus Gagge

12k 19 36

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

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

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

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

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

Finite State Machine Pattern - The One True Pattern?

Yahoo! Search

9/1/13 architecture - Finite State Machine Pattern - The One True Pattern? - Stack Overflow

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

hvgotcodes

45.8k 6 59 118

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

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 state-

chart 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

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

9/1/13 architecture - Finite State Machine Pattern - The One True Pattern? - Stack Overflow

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

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

Not the answer you're looking for? Browse other questions tagged design-patterns

architecture state-machines or ask your own question.