State pattern - Low-Level Design Guide

Overview

The State pattern lets an object change its behavior when its internal state changes, as if it changed its class. Each state is a separate class implementing the same interface; the context (a vending machine, an order, an elevator) delegates every request to its current state object, and states decide transitions.

It replaces large switch statements on a status field that appear in every method (if state == IDLE ... else if state == HAS_MONEY ...). With State, adding a new state means adding a class, and each state's rules are in one place. It is the standard implementation of a state diagram in LLD interviews.

A phone's modes

Pressing the power button does different things when the phone is locked, unlocked, or off. The button is the same; the current mode decides the behavior and which mode comes next.

When to use it

An object's behavior depends heavily on its current state.
Methods contain the same switch on a status field.
Machines and lifecycles: vending machine, ATM, elevator, order, traffic light, document workflow.

Where it shows up in interviews

Machine design

Recognize it when: device reacts differently to the same input by mode.

Design a vending machine
Design an ATM
Design an elevator system

Workflow lifecycles

Recognize it when: status with allowed transitions.

Design an order system
Design a document approval workflow

Where it is used in real software

TCP connection states

Classic example from the Gang of Four book: TCPConnection delegates to TCPEstablished, TCPListen, and TCPClosed.

Game character controllers

Idle, running, jumping, and attacking states handle input differently.

Workflow engines

Document approval and payment flows are modeled as state machines (Spring State Machine, XState).

Key terms

Context: The object whose behavior changes (VendingMachine).
State interface: Operations every state handles (insertCoin, select).
Concrete state: Behavior for one state (HasMoneyState).
Transition: A state setting the context's next state.

How it works, step by step

1
Draw the state diagram
States, events, transitions.
2
Define the state interface
One method per event.
3
Implement a class per state
Handle each event: act, transition, or reject.
4
Context delegates
machine.insertCoin() calls state.insertCoin(machine).
5
States set the next state
context.setState(new DispensingState()).

Vending machine with State pattern

IdleState

HasMoneyState

DispensingState

SoldOutState

STEP 1Context delegates insertCoin(25) to IdleState, which adds credit and switches to HasMoneyState.

How each state handles events

Vending machine, item price 100

State	insertCoin	select	cancel
Idle	Add credit, go HasMoney	Reject: insert money first	Nothing to refund
HasMoney	Add credit	If credit >= 100: Dispensing	Refund, go Idle
Dispensing	Reject: busy	Reject: busy	Reject: busy
SoldOut	Refund immediately	Reject: sold out	Refund

NOWState: Idle | insertCoin: Add credit, go HasMoney | select: Reject: insert money first | cancel: Nothing to refund

Each row is one class. No method in the machine contains a switch on state.

Implementation

1public interface MachineState {2    void insertCoin(VendingMachine m, int cents);3    void select(VendingMachine m, String code);4    void cancel(VendingMachine m);5}6 7public final class VendingMachine {8    private MachineState state = new IdleState();9    private int credit;10    private final Map<String, Integer> prices = new HashMap<>();11    private final Map<String, Integer> stock = new HashMap<>();12 13    public void insertCoin(int cents) { state.insertCoin(this, cents); }14    public void select(String code) { state.select(this, code); }15    public void cancel() { state.cancel(this); }16 17    void setState(MachineState s) { state = s; }18    void addCredit(int c) { credit += c; }19    int credit() { return credit; }20    int refund() { int r = credit; credit = 0; return r; }21    int price(String code) { return prices.getOrDefault(code, Integer.MAX_VALUE); }22    boolean inStock(String code) { return stock.getOrDefault(code, 0) > 0; }23    void dispense(String code) { stock.merge(code, -1, Integer::sum); credit -= price(code); }24    boolean anyStock() { return stock.values().stream().anyMatch(q -> q > 0); }25    public void load(String code, int price, int qty) { prices.put(code, price); stock.merge(code, qty, Integer::sum); }26}27 28final class IdleState implements MachineState {29    public void insertCoin(VendingMachine m, int cents) { m.addCredit(cents); m.setState(new HasMoneyState()); }30    public void select(VendingMachine m, String code) { System.out.println("Insert money first"); }31    public void cancel(VendingMachine m) {}32}33 34final class HasMoneyState implements MachineState {35    public void insertCoin(VendingMachine m, int cents) { m.addCredit(cents); }36    public void select(VendingMachine m, String code) {37        if (!m.inStock(code)) { System.out.println("Item unavailable"); return; }38        if (m.credit() < m.price(code)) { System.out.println("Price: " + m.price(code)); return; }39        m.dispense(code);40        System.out.println("Dispensed " + code + ", change " + m.refund());41        m.setState(m.anyStock() ? new IdleState() : new SoldOutState());42    }43    public void cancel(VendingMachine m) { System.out.println("Refund " + m.refund()); m.setState(new IdleState()); }44}45 46final class SoldOutState implements MachineState {47    public void insertCoin(VendingMachine m, int cents) { System.out.println("Sold out, returning " + cents); }48    public void select(VendingMachine m, String code) { System.out.println("Sold out"); }49    public void cancel(VendingMachine m) {}50}

Complexity and performance

Event handlingO(1) dispatch

Delegation to current state.

Classes1 per state

Plus interface and context.

Trade-offs

Classes vs a transition table

For simple transitions with little behavior, an enum table is shorter; State shines when behavior per state differs a lot.

Who owns transitions

States deciding transitions spreads the diagram across classes; a central table keeps it visible.

Variants and related techniques

State vs Strategy

Same structure; strategies are chosen by clients, states switch themselves as events occur.

Enum-based states

Java enums with abstract methods implement small state machines compactly.

Singleton states

Stateless state objects can be shared instances.

Common mistakes

Keeping state data inside state objects that get replaced.
Fix: Keep shared data (credit, stock) in the context; states hold behavior.
Forgetting invalid events.
Fix: Every state must handle every event explicitly (reject or ignore).

Interview questions

How does the State pattern differ from Strategy?

Both delegate to an interface. With Strategy, the client selects the algorithm and it rarely changes. With State, the object moves between states itself as events happen, and each state determines the next.

Why use State instead of a switch on status?

A switch repeated in every method grows with each new state and mixes all rules together. State puts each state's behavior and transitions in its own class, following SRP and OCP.

Practice problems

Problem	Difficulty	What it trains
Traffic light with pedestrian button	Easy	Timed transitions.
Vending machine with State pattern	Medium	Events and refunds.
ATM session states (card, PIN, transaction)	Medium	Security rules.