What is the State Pattern?
Learn the State design pattern in OOP — state delegation, transitions and State vs Strategy — with a Java order-lifecycle example.
Expected Interview Answer
The State pattern is a behavioral design pattern that lets an object change its behavior when its internal state changes, by delegating state-specific logic to separate state classes instead of branching on a status flag everywhere.
The context object holds a reference to a current State object and forwards requests to it. Each concrete state implements the same interface but provides its own behavior, and a state transition simply swaps which concrete state object the context is pointing to. This eliminates large conditional blocks scattered across the class, since each state class only needs to know its own behavior and which state comes next. It differs from Strategy in intent: Strategy lets a caller choose an algorithm, while State lets the object itself drive transitions as its lifecycle progresses.
- Removes large switch/if-else chains keyed on a status field
- Each state is isolated, easy to test and extend independently
- Adding a new state means adding a class, not editing existing ones
- Makes valid state transitions explicit and easier to reason about
AI Mentor Explanation
An umpire’s signal behavior changes entirely depending on the match state — during play a raised finger means out, but during a drinks break the same gesture means nothing because the "in-play" state object is no longer active. Instead of the umpire mentally checking a giant list of conditions for every situation, each match state (play, break, rain-delay) has its own defined set of valid actions. That is the State pattern: behavior is delegated to whichever state object is currently active, and transitioning to a new state changes what happens next without rewriting the umpire’s core logic.
Step-by-Step Explanation
Step 1
Define a State interface
Declare the methods that vary by state, e.g. handle(), next().
Step 2
Implement a concrete class per state
Each state class implements the interface with its own behavior.
Step 3
Give the context a current state reference
The context object holds one State instance and delegates calls to it.
Step 4
Transition by swapping the reference
A state (or the context) assigns a new State instance to move the context forward.
What Interviewer Expects
- A correct definition distinguishing State from a plain status flag
- Awareness that the context delegates to a current state object
- A clear comparison against the Strategy pattern (who decides, and why)
- A concrete state-machine example (order, connection, or media player)
Common Mistakes
- Confusing State with Strategy — the underlying UML is identical but intent differs
- Implementing states as enums with switch statements instead of delegation
- Letting the context, not the state objects, hardcode transition logic everywhere
- Forgetting that state objects can be stateless singletons if they hold no per-instance data
Best Answer (HR Friendly)
“The State pattern lets an object behave differently depending on what state it’s currently in, without a giant if-else block checking a status flag everywhere. Each state is its own class with its own logic, the object just delegates to whichever state is currently active, and moving to a new state means swapping that reference. It keeps state-specific logic organized and makes adding new states much safer.”
Code Example
interface OrderState {
void next(Order order);
String name();
}
class PlacedState implements OrderState {
public void next(Order order) { order.setState(new ShippedState()); }
public String name() { return "PLACED"; }
}
class ShippedState implements OrderState {
public void next(Order order) { order.setState(new DeliveredState()); }
public String name() { return "SHIPPED"; }
}
class DeliveredState implements OrderState {
public void next(Order order) { /* terminal state: no-op */ }
public String name() { return "DELIVERED"; }
}
class Order {
private OrderState state = new PlacedState();
void setState(OrderState state) { this.state = state; }
void advance() { state.next(this); }
String currentState() { return state.name(); }
}Follow-up Questions
- How does the State pattern differ from the Strategy pattern?
- Can concrete state objects be shared as singletons across contexts?
- Who should own the transition logic — the context or the state itself?
- How would you model an invalid transition attempt in this pattern?
MCQ Practice
1. The State pattern primarily eliminates?
It replaces sprawling if/switch logic on a status flag with delegation to per-state classes.
2. In the State pattern, who typically triggers a state transition?
Transitions are usually driven by the context or by the current state deciding the next state.
3. How does State differ from Strategy in intent?
Structurally similar, but State represents intrinsic lifecycle behavior while Strategy is caller-selected policy.
Flash Cards
State pattern in one line? — An object delegates behavior to a current state object, and transitions swap that reference.
What problem does it solve? — Large conditional blocks branching on a status field.
State vs Strategy? — State models internal lifecycle transitions; Strategy is a caller-chosen algorithm.
Adding a new state requires? — A new class implementing the state interface, not editing existing states.