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.
Output: TypeScript file and captured output
interface OrderState {
next(): OrderState
describe(): string
}
class NewOrder implements OrderState {
next(): OrderState {
return new Paid()
}
describe(): string {
return "new - waiting for payment"
}
}
class Paid implements OrderState {
next(): OrderState {
return new Shipped()
}
describe(): string {
return "paid - packing the box"
}
}
class Shipped implements OrderState {
next(): OrderState {
return this
}
describe(): string {
return "shipped - on its way"
}
}
class Order {
state: OrderState = new NewOrder()
advance(): void {
this.state = this.state.next()
}
}
const order = new Order()
console.log(order.state.describe())
order.advance()
console.log(order.state.describe())
order.advance()
console.log(order.state.describe())
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.