Skip to main content

What It Is

The State pattern gives an object different behavior in different states by making each state its own class. The object holds its current state and delegates to it; moving to another state means swapping the value.

It replaces the growing switch (status) { ... } repeated through half the methods with one small class per state.


Example: An Order's Life

An order is new, then paid, then shipped. Each state class answers describe() its own way and knows which state comes next — the order itself contains no status logic at all.

Each state is a class

advance() is one line forever, and the three printed lines come from three different classes. Adding a “delivered” state is a new class plus one changed next() — no switch to hunt through.

Prompt
Write a TypeScript program with the State pattern: an OrderState interface with next and describe, NewOrder, Paid and Shipped state classes (shipped stays shipped), and an Order class holding a state with an advance method that swaps it. Walk one order through all three states, printing each description.
Output: TypeScript file and captured output

When to Use It

Use it when an object's behavior genuinely differs by state and the states have real rules about transitions — orders, documents (draft/review/published), connections, game characters.

Skip it when a status is only displayed, never changes behavior. A string union such as "new" | "paid" | "shipped" with one switch is fine below three states with simple rules.


Pros and Cons

Pros: each state's rules live in one small class; impossible transitions are simply not written; new states extend instead of modifying.

Cons: many tiny classes for simple machines; the flow of the whole machine is spread across files — a diagram in a comment helps.