State design pattern

As explained in Software Design for Python Programmers

The State Design Pattern is a behavioral design pattern that allows an object to alter its behavior when its internal state changes by delegating state-specific behavior to separate state representations.

The State Design Pattern lets an object change its behavior when its internal state changes. It names the possible states, centralizes transitions, and delegates state-specific actions to separate state representations. section 13.0 section 13.1

A straightforward implementation keeps state variables and a large conditional branch inside the main object. Every action must account for every state, so state-specific behavior and transition logic remain concentrated in one class. section 13.1.2

Refactoring separates responsibilities:

• Represent each state with a subclass of State, such as READY, VALIDATING, TICKET_SOLD, or SOLD_OUT. section 13.1.3
• Give every state class the action methods the object supports: insert_credit_card(), check_validity(), take_ticket(), and remove_credit_card(). section 13.1.4 section 13.3
• Let the context retain the current State object and delegate each action through polymorphism. section 13.1.3
• Return the next State object from each action; returning the same object means that no transition occurs. section 13.1.3
• Use a StatesBlock to initialize and aggregate state objects, keeping the context and concrete states loosely coupled. section 13.1.3

Automatic ticket machine

A ticket machine moves from READY to VALIDATING when a card is inserted, then to TICKET_SOLD after validation. Taking the ticket decrements the count and returns either READY or SOLD_OUT. Invalid actions still receive state-specific responses, such as rejecting a card, waiting for validation, or requiring the customer to take a ticket first. section 13.1 section 13.1.3

Figure 13.1 A UML state diagram showing the four states and the state transitions of an automatic ticket machine. The machine keeps track of the number of tickets it has, whether a credit card is inserted, and the validity status of the card. Customer and machine actions (numbered, such as 1: Insert card) and certain conditions (in square brackets, such as [card invalid]) can cause transitions from one state to another. This figure only shows actions that cause transitions.

Use the state diagram to trace named states, actions, conditions, and transitions in the ticket machine. section 13.1

How Software Design for Python Programmers covers it

How deep it goes

Explains the pattern through a conditional implementation, a polymorphic refactoring, a generic model, and a pattern comparison.

Examples

Uses an automatic ticket machine with READY, VALIDATING, TICKET_SOLD, and SOLD_OUT states.

What it assumes

Assumes basic objects and instance variables while teaching named states, transitions, subclasses, and polymorphic delegation through Python.

What you can do after

Build it from scratch by separating state classes, delegating actions, and returning objects representing the next state.

How it connects

Connects state transitions, polymorphism, encapsulation, loose coupling, and the Visitor Design Pattern.

liveBookmanning.com

Read Software Design for Python Programmers on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Object-Oriented Software Design in C++A behavioral design pattern that encapsulates state-specific behavior in separate objects and delegates behavior according to an object's current state.

Compare how 2 books explain state design pattern →

Related concepts

• design patternkind of · A design pattern is a reusable, general solution structure for a recurring software design problem in a particular context.
• state transitionuses · A state transition is a change from one modeled state of a system, object, or process to another according to an event, action, condition, or rule.
• stateuses · State is information or a configuration describing the condition of a system, entity, or computation at a particular time and potentially influencing subsequent behavior or decisions.
• behavioruses · Behavior is the externally observable actions, responses, outputs, or effects of a system or object under specified conditions or interactions.
• visitor design patterncontrasts with · The Visitor pattern separates operations on an object structure into visitor objects, allowing operations to be added without changing the structure’s element classes.

This explainer was generated by Manning's knowledge graph from the text of Software Design for Python Programmers. The section links point to the parts of the book it draws on.