How to use state pattern correctly?

Question

I\'ve encountered a few implementations of state pattern in my programming experience, and done a few. I\'ve seen them used in various scenarios (mostly UI and parsing). The tro

Answer 1

have a look at Finite State Machine. Almost every mature language has own good examples. Since you haven't specified your preferred language, I'll give you C++ example: Boost FSM library. Most probably it's much more complicated than you need, but it can give you some design hints for sure

Answer 2

@Ivan: There are a number of resources available on the web for Hierarchical State Machines (HSM). Miro Samek has written extensively about this design pattern and offers a lot of helpful information.

Some articles that should be of interest:

• State-Oriented Programming (SOP) (Samek) (pdf)
• Hierarchical State Machines - a Fundamentally Important Way of Design (Samek) (pdf)
• Practical State Charts in C/C++ (Samek) (link to google-books)
• State-Oriented Programming (by Asher Sterkin) (pdf)

The big benefit of using HSM over flat FSM state charts described by Mealy and Moore is that the hierarchy creates a separation of responsibility. Sub-states only need to handle those conditions that they are expressly designed to handle--unhandled events get passed up to the parent state, if the parent state isn't expressly designed to handle it then it is passed up to the next-higher parent and so on. It allows you to create small, manageable state machines that each serve a single purpose--one that can fit within a single object. As new features are added, or as new classes are added, they only need to handle their own little part of the world and pass on the unhandled events to their respective parents.

When implemented correctly, you get a robust program with low cyclomatic complexity, that is easy to modify or upgrade as needed.

Answer 3

So I'm looking for:

• Examples of common pitfalls when implementing state pattern and how to avoid them,

The state pattern does not scale well. Just imagine a state machine with 10 states and 10 different transition types. Adding a new state means that state has to define all 10 transitions. Adding a new transition means all 10 states have to define it. In short, don't use the state pattern if your state machine isn't stable and/or you have a lot of states/transitions.

• Real world examples of state pattern done correctly (like in some open source project/framework)

Define correctly :-) The Java example cited in https://stackoverflow.com/a/2707195/1168342 is for JSF Lifecycle, but I think there is only one transition. None of the other answers cite anything for State.

• Personal experiences with state pattern are also welcome

Head First Design Patterns uses a Gumball machine example to illustrate State. It's ironic, but every time they extend the design (adding a new state or transition), there is a lot of repeated code (especially for the invalid transitions within specific states). Also, according to who decides what the next state is, individual state classes can be coupled to each other (inter-state dependencies). See the explanation at the end of this answer: https://stackoverflow.com/a/30424503/1168342.

The GoF book mentions that table-based alternatives have advantages, namely their regularity. Changing the transition criteria requires changing the table (and not the code).