State Pattern

1The problem it solves#

Start with the pain, because the pattern only makes sense once you feel it.

Picture a vending machine with four modes: idle, coin inserted, item selected, dispensing. Now write insertCoin(), selectItem(), and dispense(). Without the pattern, you get this.

void insertCoin() {
    if (state == IDLE) {
        state = HAS_COIN;
    } else if (state == HAS_COIN) {
        throw new IllegalStateException("coin already in");
    } else if (state == DISPENSING) {
        throw new IllegalStateException("wait, dispensing");
    } else if (state == SOLD_OUT) {
        refund();
    }
    // ...and the same ladder again in selectItem(), and dispense()
}

Every method grows the same if-ladder over the same enum, and the cost shows up three ways.

• Change amplification. Add one state and you now edit three methods instead of one.
• Silent bugs. Miss a branch and the machine accepts a coin while dispensing, and nothing throws.
• Smeared logic. Everything a coin-holding machine can do is scattered across all three methods, so no single file tells the full story.

What the State pattern does about it:

• Pulls each mode into its own class, so the behavior for HAS_COIN lives in one file.
• Makes transitions explicit instead of implied by which branch you fell into.
• Replaces the giant conditional with a single method call.

2The idea (mental model)#

Here is the model I use at the whiteboard.

• Context. The thing the outside world holds, like the vending machine.
• State objects. One per mode. The context delegates every request to the current one.
• The hand-off. The state does the work, and it decides which state comes next.

Two sentences that make it click:

• The context doesn't know how to behave. It only knows who it currently delegates to.
• Each state knows exactly how to behave in that mode, and which state comes next.

This is two SOLID principles made concrete:

• Open/Closed. Adding a new mode means writing a new class, not editing existing ones.
• Single Responsibility. One class per mode, one reason to change each.

3Structure#

Three moving parts, and one detail people drop.

• State (an interface). Declares the actions that can happen, like insertCoin() and dispense().
• Concrete states (IdleState, HasCoinState, and so on). Each implements the interface and holds a reference back to the context so it can trigger the next transition.
• Context (VendingMachine). Holds the current state, forwards calls to it, and exposes a setState() so states can move it along.

And the runtime flow for a happy-path purchase:

4Implementation in Java#

Keep it tight: the interface, the context, and two concrete states so the transition mechanics are visible. The rest follow the same shape.

interface State {
    void insertCoin();
    void selectItem();
    void dispense();
}

class VendingMachine {
    private State idle, hasCoin, dispensing, soldOut;
    private State current;
    private int itemCount;

    VendingMachine(int itemCount) {
        this.itemCount = itemCount;
        this.idle = new IdleState(this);
        this.hasCoin = new HasCoinState(this);
        this.dispensing = new DispensingState(this);
        this.soldOut = new SoldOutState(this);
        this.current = itemCount > 0 ? idle : soldOut;
    }

    // the context just forwards. no branching here.
    public void insertCoin()  { current.insertCoin(); }
    public void selectItem()  { current.selectItem(); }
    public void dispense()    { current.dispense(); }

    void setState(State s) { this.current = s; }

    State idle()       { return idle; }
    State hasCoin()    { return hasCoin; }
    State dispensing() { return dispensing; }
    State soldOut()    { return soldOut; }

    int itemCount() { return itemCount; }
    void releaseItem() { itemCount--; }
}

Now two states. Notice how each one owns only its own rules.

class IdleState implements State {
    private final VendingMachine vm;
    IdleState(VendingMachine vm) { this.vm = vm; }

    public void insertCoin() {
        System.out.println("coin accepted");
        vm.setState(vm.hasCoin());
    }
    public void selectItem() { System.out.println("insert a coin first"); }
    public void dispense()   { System.out.println("insert a coin first"); }
}

class HasCoinState implements State {
    private final VendingMachine vm;
    HasCoinState(VendingMachine vm) { this.vm = vm; }

    public void insertCoin() { System.out.println("coin already inserted"); }

    public void selectItem() {
        System.out.println("item selected");
        vm.setState(vm.dispensing());
        vm.dispense(); // trigger the dispense immediately
    }
    public void dispense() { System.out.println("select an item first"); }
}

And the state that does the real work and loops back:

class DispensingState implements State {
    private final VendingMachine vm;
    DispensingState(VendingMachine vm) { this.vm = vm; }

    public void insertCoin() { System.out.println("wait, dispensing"); }
    public void selectItem() { System.out.println("wait, dispensing"); }

    public void dispense() {
        vm.releaseItem();
        System.out.println("item dispensed");
        vm.setState(vm.itemCount() > 0 ? vm.idle() : vm.soldOut());
    }
}

Three choices worth defending out loud, because an interviewer will probe each:

• Reuse the state objects (flyweight). I build the four states once in the constructor and reuse them, because they are stateless: they hold only a final reference to the context. Four long-lived instances no matter how many coins go in. If a state had to carry per-visit data (say a timeout count), I would create a fresh instance per transition and accept the garbage.
• The context never checks its mode. There is not a single if on current anywhere in the context. That absence of branching is the whole point, and it is the first thing I point to when asked "how is this better than the enum?"
• Edge cases live in the graph, not in guards. The terminal soldOut case is wired from the constructor: build a machine with zero items and it starts in SoldOutState, not Idle. The state graph holds the edge cases, so they are not scattered across methods as ad-hoc checks.

5A real-world example#

The one I hit most often in real code is an order lifecycle: CREATED -> PAID -> SHIPPED -> DELIVERED, with CANCELLED hanging off the side.

Each state answers the same questions differently:

• Can you cancel? A CREATED order, yes. A SHIPPED order, no.
• Can you refund? Only after PAID.
• Can you ship? Only when PAID and in stock.

You also see this baked into frameworks and products:

• A TCP connection is a state machine (LISTEN, SYN_SENT, ESTABLISHED, CLOSE_WAIT).
• A media player (stopped, playing, paused) is the textbook case.
• Document workflows (draft, in review, published, archived) are the same shape.

Any time a product manager hands you a diagram of boxes and arrows, you are looking at a candidate for State.

6When to use it, and when not to#

Use it when:

• An object has several clearly named modes, and its behavior differs meaningfully per mode.
• You keep writing the same switch or if on a status field in multiple methods.
• Transitions have rules, and you want those rules in one obvious place.

Skip it when:

• You have two modes and one branching method. A boolean and an if is fine. Four state classes for an on/off switch is architecture cosplay.
• The states never change behavior, they only change a value. That is just a field.
• The transition logic is genuinely trivial and unlikely to grow. Don't pay the class-count tax for nothing.

The honest tradeoff:

• State turns one fat class into several small ones. Twelve states means twelve classes, so more files to open.
• The transition graph is now spread across all of them, which can make the full picture harder to see at a glance.
• But each class is small, each reason to change is isolated, and every illegal action is explicit.
• I take that trade almost every time the behavior-per-state is real, and I pair the classes with a transition diagram in the docs so the graph still lives somewhere whole.

7Common mistakes#

Putting the transition logic back in the context.

• If the context has if (current instanceof HasCoinState) setState(...), you have rebuilt the conditional you were trying to kill.
• States decide their own transitions. This is the single most common misuse, and the one an interviewer watches for.

Forgetting the back-reference.

• Without a handle on the context, a state can't trigger the next transition.
• Candidates draw the diagram without the state-to-context arrow and then can't explain how the machine moves. Draw that arrow first.

Leaking state objects everywhere.

• The outside world should only touch the context.
• If callers pass around HasCoinState directly, your encapsulation is gone and the context is no longer the single entry point.

Giant unreachable methods.

• Every state implements every action, even the ones that aren't allowed. That is the feature: a DISPENSING state explicitly rejecting insertCoin() is documentation the compiler enforces.
• If you throw the same exception in twenty methods, pull an abstract base class with sensible "not allowed here" defaults and override only what each state permits. Same guarantee, less boilerplate.

Mutable shared state objects.

• Reuse singleton state instances but store per-request data on them and you get cross-talk under concurrency: two threads sharing one HasCoinState instance stomp each other's data.
• Keep reusable states stateless, or create fresh ones per transition.

8Where it shows up in interviews#

This is a bread-and-butter LLD prompt. The classics: a vending machine, a parking lot gate, a traffic light, an ATM, an elevator, an order-processing system. All of them are state machines wearing a different hat.

What interviewers actually watch for:

• Do you spot the state machine? Starting with a status enum and a switch is your cue to say "I'll model each state as a class."
• Can you draw the states and transitions cleanly? A quick box-and-arrow diagram before any code earns a lot of trust.
• Do states own their transitions, or did you cheat and branch in the context?
• How do you handle invalid actions? "Inserting a coin while dispensing" is the edge case a good interviewer pokes at. Have an answer.
• Can you name the near-neighbor? Say "this is structurally Strategy, but the objects swap themselves on events" before they ask.

My advice for the room: name the states out loud, draw the transition arrows, then write the interface and one interesting state in full. You don't need all six classes to prove you understand it. Show the delegation, show one real transition, and talk through how invalid actions get rejected. That is the whole pattern, and it usually clears the bar in 20 minutes.

Next, compare this with the Strategy pattern (same skeleton, different intent) and try the classic Vending Machine and Elevator LLD problems to practice turning a transition diagram into state classes.