State

Real-world analogy

A modern smartphone exhibits the State pattern through its physical buttons. When the phone is in the Unlocked State, pressing the power button turns off the screen, and pressing volume buttons adjusts media sound. When the phone is in the Ringing State from an incoming call, pressing the power button silences the ringer without sleeping, and tapping the screen answers or rejects the call. When the phone is in the Depleted Battery State, pressing the power button simply displays a blinking empty-battery icon. The physical hardware buttons never change, but the phone's behavior changes completely based on its internal state.

The problem

You are designing an automated vending machine controller. The machine supports four primary operations:

• insertCoin()
• ejectCoin()
• pressButton()
• dispense()

The machine moves across four discrete states: NO_COIN, HAS_COIN, SOLD_OUT, and DISPENSING.

Without the State pattern, every single operation in the VendingMachine class contains a massive switch or if-else block checking the current state:

1 // Naive implementation: Sprawling conditionals inside every single method
2 class VendingMachine {
3   #state = "NO_COIN";
4   #inventory = 5;
5 
6   insertCoin() {
7     if (this.#state === "NO_COIN") {
8       this.#state = "HAS_COIN";
9       console.log("Coin inserted. Press button to select item.");
10     } else if (this.#state === "HAS_COIN") {
11       console.log("Coin already inserted! Eject first.");
12     } else if (this.#state === "SOLD_OUT") {
13       console.log("Machine sold out. Coin rejected.");
14     } else if (this.#state === "DISPENSING") {
15       console.log("Please wait, dispensing in progress.");
16     }
17   }
18 
19   pressButton() {
20     if (this.#state === "NO_COIN") {
21       console.log("Insert coin first!");
22     } else if (this.#state === "HAS_COIN") {
23       this.#state = "DISPENSING";
24       this.dispense();
25     } else if (this.#state === "SOLD_OUT") {
26       console.log("Sold out!");
27     } else if (this.#state === "DISPENSING") {
28       console.log("Already dispensing.");
29     }
30   }
31 
32   dispense() {
33     // Another 4-way switch statement duplicated here...
34   }
35 }

1 public class Example {
2     static class VendingMachine {
3         enum State { NO_COIN, HAS_COIN, DISPENSING, SOLD_OUT }
4         State state = State.NO_COIN;
5 
6         public void insertCoin() {
7             switch (state) {
8                 case NO_COIN -> { state = State.HAS_COIN; System.out.println("Coin accepted"); }
9

Adding a fifth state (such as MAINTENANCE_MODE or PROCESSING_CREDIT_CARD) requires modifying every method in the class, risking regressions in unrelated states and violating the Open/Closed Principle.

The solution

The State pattern extracts all state-specific behavior into a hierarchy of separate State classes. The context holds a reference to its current state object and delegates all actions to it. When an event occurs, the state object transitions the context to a new state instance.

• Context (VendingMachine): Maintains the current state instance and public interface.
• State (VendingState): Interface declaring all available actions (insertCoin, pressButton, ejectCoin, dispense).
• Concrete States (NoCoinState, HasCoinState, SoldOutState): Implements state-specific responses and triggers transitions.

Step-by-step implementation

Step 1: Define the state interface

Declare all methods that the context can invoke.

Step 2: Implement the context class

The context delegates operations to its current state and provides a package-private method to swap states.

Step 3: Implement concrete state classes

Concrete states encapsulate valid actions and transition the context to next states.

The complete example

Here is the complete, runnable implementation of a Vending Machine with transitions across NoCoin, HasCoin, and SoldOut.

1 --- Customer 1: Normal Purchase ---
2 Payment required. Please insert a coin first.
3 Coin accepted. Please make a selection.
4 Selection confirmed.
5 [Machine] Item dispensed! Remaining stock: 1
6 
7 --- Customer 2: Insert and Change Mind ---
8 Coin accepted. Please make a selection.
9 Coin returned.
10 
11 --- Customer 3: Purchase Last Item ---
12 Coin accepted. Please make a selection.
13 Selection confirmed.
14 [Machine] Item dispensed! Remaining stock: 0
15 

Variations

State transition tables vs state classes

1. Polymorphic State Classes (GoF): State-specific logic and transitions are encapsulated within concrete classes. Adding a new state requires creating a new class without modifying existing classes. However, visualising all transitions across the entire system requires reading through all state files.
2. State Transition Tables: A central 2D matrix or map defines transitions: (CurrentState, Event) -> (NextState, Action). This provides a single declarative dashboard of all legal transitions, making illegal transitions immediately detectable.

Who owns the state transitions?

• State-Driven Transitions: Concrete states know about next states and call context.setState(new NextState()). This encapsulates state flow within state classes but couples state classes to one another.
• Context-Driven Transitions: Concrete states only return status flags or error codes, and the Context determines which state to transition into next. This keeps state classes decoupled from each other but adds transition conditional logic to the context.

Where you've already used it

• TCP Network Sockets: Sockets change behavior based on TCP state (CLOSED, LISTEN, SYN_SENT, ESTABLISHED).
• Spring State Machine: Enterprise state machine framework for modeling order fulfillment, insurance claims, and multi-step payment approvals.
• XState / Frontend Statecharts: Finite state machine library for React and Vue modeling UI modal and form validation workflows.
• Game Engine AI: Non-player characters transitioning between Idle, Patrol, Alert, Chase, and Attack states.

Pros and cons

When not to use it

Do not use State if an object only has two states and rarely changes behavior (e.g. an active/inactive boolean flag). A simple boolean check is much simpler than creating an interface and two separate state classes.

Related patterns

Interview questions

How does State differ from Strategy? Strategy algorithms are chosen and injected by the client, and strategies are independent and unaware of each other. In State, the context transitions between states automatically as events occur, and state classes frequently know about and instantiate other states.

What is the trade-off between State-driven vs Context-driven transitions? State-driven transitions encapsulate the progression rules cleanly within each state, but introduce coupling between state classes. Context-driven transitions keep states completely decoupled, but clutter the context with conditional transition rules.

Can State objects be shared across multiple context instances? Yes, if the state objects are stateless flyweights (holding no mutable instance fields). If state objects must store local timers, counters, or references to a specific context, each context must instantiate its own state instances.

How does the State pattern satisfy the Open/Closed Principle? New states can be added to the system by introducing a new State subclass without modifying existing state classes or the context class.