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

As you probably have read, the State Design Pattern is useful when state varies the behavior of some object whose composition includes that state. This implies the idea of a State abstract class, interface, or enumerated type - albeit depending on the language Duck Typing will do as well - that defines any common behavior and/or required methods.

Key Aspects

There are really two key aspects to consider in working with the state pattern: enumeration and transition. Enumeration simply means identifying the set of possible states (e.g. days of the week), or more abstractly the types of states (i.e. meta states) such as starting, ending, and in between for a workflow engine.Transition means deciding how to model movement between states where this is typically either done by capturing all possible transitions in a tabular representation (i.e. Finite State Machine) or make each state know its possible "transitions" to other states.

Typically transitions go hand in hand with meta states because its not possible to know all states and relationships ahead of time in such a dynamic system where new states, and thus transitions, can be added at runtime. In addition, with the transition approach, certain behavior - notifications for instance - becomes part of the transition, instead of the state itself.

Examples

There are several scenarios I've either worked on or discussed where this is a use facility:

1. Workflow
2. Computer Game Opponent A.I.
3. Process Orchestration

By workflow I mean something like jBPM. Systems like this are concerned with commanding the right attention, of the right people, at the right time. They usually send lots of emails or some other sort of notification. And, the process they represent needs the ability to change as the organization changes, whereas the data being managed typically changes much more slowly.

Computer Game Opponent A.I. is self explanatory. Not something I've written, but in conversation with those who have, these systems are usually self contained. In other words, unlike workflow, the game usually doesn't have the facility to alter the process used to control computer opponents.

Process Orchestration is similar to workflow, but focused on system integration, instead of people interaction. The Apache Mule framework is an example. Here state can describe status (e.g. started, in process, ended) and type (e.g. ftp integration point, sql integration point).

Conclusion

Unlike other answers, I think state encapsulation is an excellent way to manage change in software systems. Done well, it facilitates those changes or enables users to do so at runtime. You make a tradeoff of more flexibility in exchange for increased implementation complexity. So such an approach is probably not useful for shopping cart for instance, where the behavior is probably very well known and not like to change. On the other hand when the process is subject to change, it makes a very good fit.