State Pattern
The State pattern is a behavioral object-oriented design pattern that lets an object alter its behavior when its internal state changes, by delegating state-specific behavior to separate state objects rather than using large conditional…
Definition
The State pattern is a behavioral object-oriented design pattern that lets an object alter its behavior when its internal state changes, by delegating state-specific behavior to separate state objects rather than using large conditional statements, making the object appear to change its class at runtime.
Overview
The State pattern is one of the classic Gang of Four (GoF) behavioral design patterns. It addresses a common problem: objects whose behavior depends heavily on an internal mode or state, which without the pattern tends to be implemented as large if/else or switch statements scattered across every method, checking the current state and branching accordingly. As the number of states and methods grows, this conditional logic becomes increasingly difficult to maintain and extend. The State pattern solves this by extracting each state into its own class implementing a common state interface, with the state-specific behavior for each method living inside its corresponding state class instead of inside conditional branches. The original 'context' object holds a reference to its current state object and delegates behavior-dependent method calls to it. Transitioning between states simply means swapping which state object the context currently references, either from within the state classes themselves or from the context. A canonical example is a traffic light or a media player: rather than a `Player` class checking `if (state == PLAYING)` throughout its methods, separate `PlayingState`, `PausedState`, and `StoppedState` classes each implement `play()`, `pause()`, and `stop()` with behavior appropriate to that state, including deciding what the next state should be. This makes adding a new state as simple as adding a new class, without touching existing state classes, aligning with the open/closed principle. The State pattern is closely related to the Strategy pattern structurally — both involve delegating behavior to an interchangeable object — but differs in intent: Strategy is about choosing an algorithm from the outside, while State is about an object's own internal, self-managed state transitions, often with the state objects themselves controlling when and how transitions occur.
Key Concepts
- Encapsulates state-specific behavior in dedicated state classes
- Context object delegates behavior to its current state object
- Eliminates large conditional (if/switch) blocks checking internal state
- State transitions occur by replacing the referenced state object
- State classes can control their own transitions to other states
- Adheres to the open/closed principle when adding new states
- Structurally similar to, but conceptually distinct from, the Strategy pattern
- One of the original 23 Gang of Four design patterns
Use Cases
Frequently Asked Questions
From the Blog
How to Manage State in React Applications
Managing React state means choosing the right tool for each need: local useState, shared Context, server-state libraries, or a global store like Redux or Zustand.
Read More ProgrammingHow React Works: Rendering, State, and Reconciliation
React runs your components to produce a description of the UI, compares it with the previous description, and applies the differences to the DOM. Learn the render-and-commit cycle, why state updates are batched, how reconciliation uses keys, and how that explains most of the bugs you will hit.
Read More ProgrammingManaging server state in React: caching, refetching and staleness
Fetched data is a cache of something you do not own, and storing it in ordinary component state is what produces duplicate requests, stale views and out-of-order responses. This covers the behaviours that cache needs — deduplication, staleness, invalidation, race handling — and what you take on by hand-rolling them.
Read More ProgrammingReact Context vs a state management library
Context is a dependency-injection mechanism, not a state manager: it has no selector granularity, so every consumer re-renders when the value changes. This sets out when that is fine, how far splitting contexts gets you, and what a store actually adds beyond avoiding prop drilling.
Read More