State Pattern · Design Patterns

What is the State pattern?

State means: an object changes its behavior when its internal state changes, by moving each mode’s logic into its own small class.

From the outside it can look like the object changed class. What an action does is no longer decided by a big switch inside one method — it is decided by whichever state object is currently active.

Three pieces work together:

Context — the object callers talk to (Order, VendingMachine).
State interface — the actions that depend on mode (pay, ship).
Concrete states — one class per mode, each implementing those actions its own way.

The context holds the current state and delegates every action to it. When a transition happens, a different state object gets swapped in.

The problem it solves

A first draft of order status logic often looks like this:

if status == "DRAFT":
    pass  # allow pay
elif status == "PAID":
    pass  # allow ship
elif status == "SHIPPED":
    pass  # reject most actions

if (status.equals("DRAFT")) {
    // allow pay
} else if (status.equals("PAID")) {
    // allow ship
} else if (status.equals("SHIPPED")) {
    // reject most actions
}

switch status {
case "DRAFT":
	// allow pay
case "PAID":
	// allow ship
case "SHIPPED":
	// reject most actions
}

if (status === 'DRAFT') {
  // allow pay
} else if (status === 'PAID') {
  // allow ship
} else if (status === 'SHIPPED') {
  // reject most actions
}

Every new status multiplies branches. Every action method repeats similar checks, and invalid transitions are easy to miss. State moves each mode’s rules into its own class, so pay() in Draft never shares a method body with pay() in Shipped.

The state interface and context

from abc import ABC, abstractmethod


class OrderState(ABC):
    @abstractmethod
    def name(self) -> str: ...

    @abstractmethod
    def pay(self, order: "Order") -> None: ...

    @abstractmethod
    def ship(self, order: "Order") -> None: ...


class Order:
    def __init__(self) -> None:
        self._state: OrderState = Draft()

    def set_state(self, state: OrderState) -> None:
        self._state = state

    def status(self) -> str:
        return self._state.name()

    def pay(self) -> None:
        self._state.pay(self)

    def ship(self) -> None:
        self._state.ship(self)

public interface OrderState {
    String name();
    void pay(Order order);
    void ship(Order order);
}

public class Order {
    private OrderState state = new Draft();

    void setState(OrderState state) {
        this.state = state;
    }

    public String status() {
        return state.name();
    }

    public void pay() {
        state.pay(this);
    }

    public void ship() {
        state.ship(this);
    }
}

type OrderState interface {
	Name() string
	Pay(order *Order) error
	Ship(order *Order) error
}

type Order struct {
	state OrderState
}

func NewOrder() *Order {
	return &Order{state: Draft{}}
}

func (o *Order) SetState(state OrderState) {
	o.state = state
}

func (o *Order) Status() string {
	return o.state.Name()
}

func (o *Order) Pay() error {
	return o.state.Pay(o)
}

func (o *Order) Ship() error {
	return o.state.Ship(o)
}

interface OrderState {
  name(): string;
  pay(order: Order): void;
  ship(order: Order): void;
}

class Order {
  private state: OrderState = new Draft();

  setState(state: OrderState) {
    this.state = state;
  }

  status() {
    return this.state.name();
  }

  pay() {
    this.state.pay(this);
  }

  ship() {
    this.state.ship(this);
  }
}

The concrete states

class Draft(OrderState):
    def name(self) -> str:
        return "Draft"

    def pay(self, order: "Order") -> None:
        order.set_state(Paid())

    def ship(self, order: "Order") -> None:
        raise ValueError("pay first")


class Paid(OrderState):
    def name(self) -> str:
        return "Paid"

    def pay(self, order: "Order") -> None:
        raise ValueError("already paid")

    def ship(self, order: "Order") -> None:
        order.set_state(Shipped())


class Shipped(OrderState):
    def name(self) -> str:
        return "Shipped"

    def pay(self, order: "Order") -> None:
        raise ValueError("already shipped")

    def ship(self, order: "Order") -> None:
        raise ValueError("already shipped")

public class Draft implements OrderState {
    public String name() { return "Draft"; }

    public void pay(Order order) {
        order.setState(new Paid());
    }

    public void ship(Order order) {
        throw new IllegalStateException("pay first");
    }
}

public class Paid implements OrderState {
    public String name() { return "Paid"; }

    public void pay(Order order) {
        throw new IllegalStateException("already paid");
    }

    public void ship(Order order) {
        order.setState(new Shipped());
    }
}

public class Shipped implements OrderState {
    public String name() { return "Shipped"; }

    public void pay(Order order) {
        throw new IllegalStateException("already shipped");
    }

    public void ship(Order order) {
        throw new IllegalStateException("already shipped");
    }
}

type Draft struct{}

func (Draft) Name() string { return "Draft" }

func (Draft) Pay(order *Order) error {
	order.SetState(Paid{})
	return nil
}

func (Draft) Ship(order *Order) error {
	return errors.New("pay first")
}

type Paid struct{}

func (Paid) Name() string { return "Paid" }

func (Paid) Pay(order *Order) error {
	return errors.New("already paid")
}

func (Paid) Ship(order *Order) error {
	order.SetState(Shipped{})
	return nil
}

type Shipped struct{}

func (Shipped) Name() string { return "Shipped" }

func (Shipped) Pay(order *Order) error {
	return errors.New("already shipped")
}

func (Shipped) Ship(order *Order) error {
	return errors.New("already shipped")
}

class Draft implements OrderState {
  name() {
    return 'Draft';
  }

  pay(order: Order) {
    order.setState(new Paid());
  }

  ship(_order: Order) {
    throw new Error('pay first');
  }
}

class Paid implements OrderState {
  name() {
    return 'Paid';
  }

  pay(_order: Order) {
    throw new Error('already paid');
  }

  ship(order: Order) {
    order.setState(new Shipped());
  }
}

class Shipped implements OrderState {
  name() {
    return 'Shipped';
  }

  pay(_order: Order) {
    throw new Error('already shipped');
  }

  ship(_order: Order) {
    throw new Error('already shipped');
  }
}

Usage reads like a story:

order = Order()
print(order.status())  # Draft
order.pay()
print(order.status())  # Paid
order.ship()
print(order.status())  # Shipped

Order order = new Order();
System.out.println(order.status()); // Draft
order.pay();
System.out.println(order.status()); // Paid
order.ship();
System.out.println(order.status()); // Shipped

order := NewOrder()
fmt.Println(order.Status()) // Draft
order.Pay()
fmt.Println(order.Status()) // Paid
order.Ship()
fmt.Println(order.Status()) // Shipped

const order = new Order();
console.log(order.status()); // Draft
order.pay();
console.log(order.status()); // Paid
order.ship();
console.log(order.status()); // Shipped

Invalid moves fail in the state that knows they are invalid — not in a shared swamp of conditionals.

A vending-machine sketch

A classic teaching example is a machine with modes like “no coin,” “has coin,” and “sold.” The context exposes insertCoin(), selectProduct(), and dispense(). Each state implements those methods differently:

In no coin, insertCoin moves to has-coin; dispense refuses.
In has coin, selectProduct moves toward sold; another coin might be rejected or queued.
In sold, dispense finishes the sale and returns to no-coin (or “sold out”).

You do not need to memorize every transition. The lesson is the structure: context delegates, states decide, transitions replace the state object.

State vs Strategy

Both patterns look similar: a context holds a helper object and delegates. The intent differs.

Strategy picks an algorithm. The context usually does not change strategy by itself after every call — the caller chooses.

State models a life cycle. Actions cause transitions. The next behavior depends on where you are in that cycle.

If you are swapping formulas, think Strategy. If you are modeling modes and allowed moves, think State.

When it helps

Use State when behavior changes sharply by mode, transition rules are getting hard to follow in one class, or you want invalid moves to be obvious in one place per mode.

It is especially helpful when new states are likely — adding a Refunded mode should not require editing every method in a large context class.

When it hurts

If you only have two booleans and three ifs, State is heavier than the problem. Do not build a framework of state classes for a toggle.

Also avoid putting unrelated business logic into state classes until they become a second god-object. States should own mode behavior and transitions, not your whole domain model.

Practical tips

Name states after domain language (Draft, Paid, Shipped), not implementation tricks.
Keep the context’s API stable; let states vary underneath.
Decide who triggers transitions — usually the state methods call back into the context.
Document the legal transitions, even with a small comment diagram.
Prefer failing loudly on illegal actions during development; silent no-ops hide bugs.

Check your understanding

State in one line?
Each mode’s behavior lives in its own class, swapped as the object’s life cycle moves.

What does the context do?
It holds the current state and forwards actions to it.

Why not just use a status string and switches?
Switches grow with every state and action; State localizes each mode’s rules.

How is it different from Strategy?
Strategy selects an algorithm. State models transitions between modes.

What to learn next

Next: Template Method Pattern — a base class fixes the steps of an algorithm while subclasses fill in the parts that vary.