Strategy vs State Pattern
Strategy vs State pattern explained — client-selected algorithms vs self-transitioning object behavior — with Java code examples.
Expected Interview Answer
The Strategy pattern lets a client choose an interchangeable algorithm at will and injects it into a context, while the State pattern lets an object change its own behavior automatically as its internal state transitions, often triggering the next state itself.
Structurally, both patterns look identical: a context class holds a reference to an interface, and concrete implementations provide different behavior. The difference is in intent and control flow. With Strategy, the client explicitly picks and swaps the algorithm (e.g. choosing a compression strategy), and strategies typically do not know about each other or trigger transitions. With State, the context’s behavior changes based on internal state, and concrete states often hold the responsibility for transitioning the context to the next state themselves, modeling something like a finite state machine (an Order moving from Pending to Shipped to Delivered). Strategy is about “which algorithm to run”; State is about “what this object can currently do, and what it becomes next.”
- Strategy eliminates conditional logic for choosing an algorithm
- State eliminates large conditional blocks for state-dependent behavior
- Both follow the open/closed principle by adding new classes instead of editing existing ones
- Both use composition to delegate behavior to an interchangeable object
AI Mentor Explanation
Strategy is a captain choosing a bowling strategy before an over — pace, spin, or a defensive line — the captain explicitly selects it and can swap it any time based on the situation. State is a match itself transitioning through phases — powerplay, middle overs, death overs — where the rules and available options change automatically as the match progresses, and the match itself drives the transition to the next phase. One is a deliberate external choice; the other is an automatic internal progression.
Step-by-Step Explanation
Step 1
Identify who drives the change
If the client explicitly selects behavior, it is Strategy; if the object transitions itself based on internal conditions, it is State.
Step 2
Strategy: define an algorithm interface
Concrete strategies implement the interface, and the client injects the chosen one into the context.
Step 3
State: define a state interface with transition awareness
Concrete states implement behavior for that state and often call context.setState(next) to move forward.
Step 4
Check for self-transition
If a concrete implementation triggers moving to the next implementation itself, it is State; if it never does, it is Strategy.
What Interviewer Expects
- Recognition that the two patterns share identical UML structure
- Clear articulation of the intent difference: client-selected vs self-transitioning
- A concrete example of each (payment strategy vs order lifecycle state machine)
- Awareness that State often models a finite state machine explicitly
Common Mistakes
- Claiming Strategy and State are structurally different patterns
- Missing that concrete states often trigger their own transitions
- Using State pattern for something that never actually changes behavior over time
- Confusing State pattern with simply using an enum with a switch statement
Best Answer (HR Friendly)
“Strategy is when the client explicitly picks which algorithm an object should use, like choosing a sorting method, and can swap it whenever. State is when an object changes its own behavior automatically as it moves through different internal states, like an order going from pending to shipped to delivered, often deciding for itself when to move to the next state. They look the same in code structure, but who is in control of the change is different.”
Code Example
interface PaymentStrategy {
void pay(double amount);
}
class CreditCardStrategy implements PaymentStrategy {
public void pay(double amount) { System.out.println("Paid " + amount + " by card"); }
}
class Checkout {
private PaymentStrategy strategy;
Checkout(PaymentStrategy strategy) { this.strategy = strategy; }
void process(double amount) { strategy.pay(amount); }
}
// client explicitly chooses the strategy
Checkout checkout = new Checkout(new CreditCardStrategy());
checkout.process(49.99);interface OrderState {
void next(Order order);
}
class PendingState implements OrderState {
public void next(Order order) {
System.out.println("Shipping order");
order.setState(new ShippedState());
}
}
class ShippedState implements OrderState {
public void next(Order order) {
System.out.println("Order delivered");
order.setState(new DeliveredState());
}
}
class DeliveredState implements OrderState {
public void next(Order order) { System.out.println("Already delivered"); }
}
class Order {
private OrderState state = new PendingState();
void setState(OrderState state) { this.state = state; }
void advance() { state.next(this); } // the state itself drives the transition
}Follow-up Questions
- Can Strategy and State share the exact same UML class diagram?
- How would you implement State without letting concrete states know about each other?
- When would a switch statement be preferable to the State pattern?
- How does State pattern relate to a finite state machine?
MCQ Practice
1. In the Strategy pattern, who typically selects the concrete algorithm?
Strategy is client-driven: the client explicitly chooses and injects the algorithm into the context.
2. In the State pattern, transitions to the next state are commonly triggered by?
Concrete states often call back into the context to set the next state, modeling automatic transitions.
3. Strategy and State patterns are structurally?
Both use a context holding a reference to an interface with interchangeable implementations; intent is what differs.
Flash Cards
Strategy in one line? — Client explicitly selects and injects an interchangeable algorithm into a context.
State in one line? — An object changes behavior automatically as its internal state transitions, often self-triggered.
Structural difference? — None — both share the same context-plus-interface shape; intent differs.
Classic State example? — An Order moving through Pending, Shipped, Delivered states.