The State Design Pattern organizes an object whose behavior changes during runtime. It names the possible states, places each state’s actions in a separate class, and lets the current state determine behavior and transitions. section 13.0 section 13.2
A typical refactoring proceeds from a centralized implementation to state-specific behavior:
- Start with one context object holding state data and implementing every action with a switch over the current state. section 13.1.2
- Recognize the change leak: every action must understand every state, so adding or changing a state spreads conditional logic across multiple functions. section 13.1.2 section 13.1.3
- Define an abstract State interface whose action methods return the next State object. section 13.1.3
- Implement one subclass per state, encapsulating that state’s response to every action and returning either another state or itself. section 13.1.3 section 13.2
- Keep the context responsible for shared data and delegation, while an aggregate such as StatesBlock constructs and connects the state objects. section 13.1.3
Automatic ticket machine
A ticket machine moves among READY, VALIDATING, TICKET_SOLD, and SOLD_OUT. In the initial design, insert_credit_card(), check_validity(), take_ticket(), and remove_credit_card() each handle all four states. In the refactored design, READY, VALIDATING, TICKET_SOLD, and SOLD_OUT implement those actions separately. For example, a successful validity check returns TICKET_SOLD, taking the final ticket returns SOLD_OUT, and an invalid action can return the current state without changing behavior. section 13.1 section 13.1.2 section 13.1.3
Figure 13.3 The subclasses of superclass State encapsulate handling the customer and machine actions for each state of the ticket machine. Each action member function of the subclasses returns a State object that is the next state for the ticket machine to transition to. By aggregating the subclasses in class StatesBlock, the subclasses are loosely coupled with each other, and class TicketMachine is loosely coupled with the State subclasses. Each action member function of class TicketMachine defers to the corresponding member function of the current State object pointed to by the private state member variable.
Use the architecture diagram to trace how TicketMachine delegates actions to the current State object and how state subclasses return transition targets. section 13.1.3
