State Pattern

Analogy categoryAnalogies

What Is the State Pattern?

The State pattern lets an object alter its behavior when its internal state changes, by extracting each state into its own class that implements a shared interface, and having the object (the Context) delegate behavior-dependent calls to whichever State object currently represents it. Instead of a field like status and a sprawl of if(status == X) checks throughout the class, each State subclass implements the same methods differently, and state transitions are handled by swapping which State instance the Context is currently holding.

🏏

Cricket analogy: A match's phase — powerplay, middle overs, death overs — changes fielding restriction rules automatically; modeling each phase as its own State object means the fielding-rule logic for death overs lives entirely separately from powerplay logic.

Structure: Context and State Objects

The Context class holds a reference to the current State object and exposes public methods (like handle() or request()) that simply forward to the current state's corresponding method; each ConcreteState implements those same methods, and crucially, a ConcreteState's method implementation is what decides to transition the Context to a different state, often by calling context.setState(new NextState()) itself. This means transition logic is distributed across the states themselves rather than centralized in one big state machine method, which keeps each state's rules self-contained.

🏏

Cricket analogy: The umpire (Context) forwards every ball's outcome to whichever phase-state is active; the DeathOversState itself decides when to hand control to a SuperOverState if scores are tied, rather than a giant central rulebook checking every condition.

typescript

interface OrderState {
  ship(context: Order): void;
  cancel(context: Order): void;
}

class PendingState implements OrderState {
  ship(context: Order): void {
    console.log('Shipping order...');
    context.setState(new ShippedState());
  }
  cancel(context: Order): void {
    console.log('Order cancelled');
    context.setState(new CancelledState());
  }
}

class ShippedState implements OrderState {
  ship(): void {
    console.log('Already shipped, cannot ship again');
  }
  cancel(): void {
    console.log('Cannot cancel a shipped order');
  }
}

class CancelledState implements OrderState {
  ship(): void { console.log('Cannot ship a cancelled order'); }
  cancel(): void { console.log('Already cancelled'); }
}

class Order {
  private state: OrderState = new PendingState();
  setState(state: OrderState): void { this.state = state; }
  ship(): void { this.state.ship(this); }
  cancel(): void { this.state.cancel(this); }
}

const order = new Order();
order.ship();
order.cancel();

State Transitions

A key design decision is where transition logic lives: letting each ConcreteState decide its own next state (as above) keeps the pattern flexible and true to its intent, but for state machines with many states and complex transition rules, teams sometimes centralize transitions in the Context or a separate table-driven state-machine library instead, trading some of the pattern's purity for a single place to audit all valid transitions. Either way, illegal transitions should be prevented at compile time or by throwing explicitly, rather than silently doing nothing, since silent no-ops are a common source of confusing bugs in state machines.

🏏

Cricket analogy: A match can't skip from 'first innings' straight to 'result declared' without passing through 'second innings' — a well-built scoring system throws an error on an out-of-sequence update rather than silently ignoring it.

For very complex workflows (dozens of states, many conditional transitions), consider a table-driven finite-state-machine library instead of hand-writing the State pattern. It sacrifices some object-oriented elegance for a single, auditable transition table that's easier to visualize and test exhaustively.

State vs Strategy Revisited

Building on the earlier comparison, State's defining trait is that ConcreteState objects are often aware of, and responsible for transitioning to, their sibling states, which introduces a form of coupling between state classes that Strategy deliberately avoids — ConcreteStrategy classes should never know about each other. This is a useful litmus test when refactoring: if your 'strategies' are starting to reference and switch to other strategies based on internal events, you're actually implementing State, and should rename and restructure accordingly to make that transition logic explicit and testable.

🏏

Cricket analogy: If your 'BowlingStrategy' classes start checking the current over count and switching to a different BowlingStrategy themselves, you've drifted into State pattern territory, since a true Strategy for choosing a bowler shouldn't reference other bowler choices.

Avoid letting every ConcreteState reference every other ConcreteState class directly, since that creates a tightly coupled web that's hard to change. Prefer having states return a transition signal or type that the Context resolves, or centralize the transition table, especially as the number of states grows.

State lets an object change behavior by delegating to interchangeable State objects instead of scattering status checks.
The Context forwards calls to its current State object and exposes a setState() method to swap states.
Each ConcreteState typically decides its own transition to the next state, distributing transition logic across states.
For complex state machines, centralizing transitions in a table-driven approach can be more auditable than pure OO delegation.
Illegal transitions should be explicitly rejected (thrown or type-blocked), never silently ignored.
State and Strategy share the same UML shape but differ in intent: State objects self-transition, Strategy objects don't.
If 'Strategy' classes start referencing each other to trigger transitions, that's actually State pattern behavior in disguise.

Practice what you learned

1. What problem does the State pattern primarily solve?

2. In a typical State pattern implementation, which object usually decides to transition the Context to a different state?

3. Why should illegal state transitions be explicitly rejected rather than silently ignored?

4. What is the key structural difference between State and Strategy, given that both delegate to a pluggable object through a shared interface?

5. A document-editing feature has statuses draft, in-review, and published, where each status allows different actions (edit, approve, publish) and specific statuses trigger the next one. Which pattern fits best?

Was this page helpful?

Command Pattern

Template Method Pattern