State

The three participants

A textbook State setup has three moving parts, and once you see them in the player example you'll recognize them everywhere:

• Context — the object the outside world talks to. Here it's the Player. It holds one field, current: State, and its public methods (pressPlay(), pressStop()) do nothing but forward the call to current. The context contains zero mode-specific logic.
• State interface — one small interface with one method per action the context supports: pressPlay(player), pressStop(player). Every concrete state must answer all of them, so no mode can 'forget' to handle an action.
• Concrete states — one class per mode: StoppedState, PlayingState, PausedState. Each implements the actions the way that mode behaves, and — crucially — each decides the next state by calling player.setState(new PlayingState()).

interface State {
  pressPlay(player: Player): void;
  pressStop(player: Player): void;
}

class Player {
  current: State = new StoppedState();   // start stopped
  setState(s: State) { this.current = s; }

  // the context only delegates — no switch, no flags
  pressPlay() { this.current.pressPlay(this); }
  pressStop() { this.current.pressStop(this); }
}

class StoppedState implements State {
  pressPlay(p: Player) {
    console.log("▶ start from 0:00");
    p.setState(new PlayingState());      // the STATE picks the next state
  }
  pressStop() { console.log("already stopped"); }
}

class PlayingState implements State {
  pressPlay(p: Player) {
    console.log("⏸ pause");
    p.setState(new PausedState());
  }
  pressStop(p: Player) {
    console.log("⏹ stop");
    p.setState(new StoppedState());
  }
}

Follow one call through: you press play while music is playing. player.pressPlay() runs this.current.pressPlay(this). Because current happens to be a PlayingState, that class's version runs — it pauses playback and swaps the player over to a fresh PausedState. The next pressPlay() lands on PausedState and resumes. The player object never asked "what state am I in?" — polymorphism answered the question for it.

Transitions live inside the states

This is the detail people miss on first read: it's not just that behavior is split into classes — the transition logic moves too. StoppedState.pressPlay() ends with player.setState(new PlayingState()). Each state knows which states can legally follow it, so the whole transition map is spelled out in the state classes themselves, not scattered across the context. Illegal moves become trivially easy to express: StoppedState.pressStop() simply does nothing (or logs "already stopped") — there's no way to accidentally fall through to the wrong branch of a shared switch.

The smell this pattern cures

Here's the code State replaces — and why it rots. Notice it's the same three-way branch, duplicated once per method:

class Player {
  state = "STOPPED";               // a string flag

  pressPlay() {
    switch (this.state) {          // branch #1
      case "STOPPED": /* start */  this.state = "PLAYING"; break;
      case "PLAYING": /* pause */  this.state = "PAUSED";  break;
      case "PAUSED":  /* resume */ this.state = "PLAYING"; break;
    }
  }
  pressStop() {
    switch (this.state) { /* branch #2 — same three cases again */ }
  }
  pressNext() {
    switch (this.state) { /* branch #3 — and again... */ }
  }
}

• Adding a state = editing every method. Introduce "BUFFERING" and you must find and extend every switch — miss one and you have a silent bug that only shows up in that mode.
• With the pattern, adding a state = adding one class. BufferingState implements the interface, existing classes barely change, and the compiler tells you exactly which methods the new mode must handle. That's [[open-closed]] in action: open to new states, closed to modification of the old ones.
• The branches drift apart. Three copies of the same switch never stay in sync — someone fixes the PAUSED case in pressPlay() but forgets it in pressStop().

State vs Strategy — same skeleton, different soul

Structurally, State looks identical to [[strategy]]: a context holding a reference to an interface, delegating calls, swapping the concrete object to change behavior. The difference is who swaps it and when. With Strategy, the client picks one algorithm up front ("sort with quicksort") and it rarely changes afterwards — the strategies don't know each other exist. With State, the object transitions itself: PlayingState knows about PausedState and actively installs it. States form a connected map of who-follows-whom; strategies are interchangeable strangers. If your objects hop between behaviors on their own as events happen, it's State. If a caller chooses one behavior and sticks with it, it's Strategy.

Where you'll meet it in the wild

• Order lifecycle — Placed → Paid → Shipped → Delivered, where cancel() behaves differently (or is forbidden) in each stage.
• TCP connection — the classic GoF example: Established, Listening, Closed, each handling open()/close()/send() in its own way.
• Vending machine — NoCoin, HasCoin, Dispensing: pressing the button with no coin does nothing; with a coin it vends.
• Document workflow — Draft → InReview → Published, where publish() is only meaningful from certain states and edit() may bounce a document back to Draft.
• Game character modes — Standing, Jumping, Ducking: the same controller button kicks, dives, or slides depending on the character's current mode.

Reach for State when behavior follows a mode

• Behavior visibly depends on a mode that changes at runtime. The same method call must do genuinely different things depending on the object's current condition — play/pause/resume, open/close a connection, cancel an order.
• Fat conditionals on a state flag in several methods. If you see the same switch (this.state) (or if/else chain) copy-pasted across three or more methods, the State pattern is the standard refactoring — each case column becomes one class.
• The object has an explicit lifecycle. Orders, documents, connections, and jobs all march through named stages with rules about which moves are legal. Encoding each stage as a class makes the legal moves explicit and the illegal ones impossible to reach.
• You already drew it. If the design phase produced a [[state-diagrams]] chart, the State pattern is the most direct translation: one class per circle, one setState call per arrow.

When NOT to use it

• Two trivial states — a boolean is fine. A checkbox that's checked or not, a modal that's open or closed: if (this.isOpen) in one or two places is clearer than four classes. State earns its keep at roughly three-plus states or three-plus methods that branch on the mode.
• The branching lives in exactly one method. A single switch in a single function isn't a smell — it's just a switch. The pattern pays off when the same branching is duplicated across many methods.
• States never transition at runtime. If the 'mode' is picked once at construction and never changes, what you want is probably [[strategy]] (or plain configuration), not State.