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
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).