What's the difference between the State and Strategy patterns?
Design patternsMid-level
In shortThey have the same structure, a context delegating to an interchangeable object, but different control. With Strategy, the client chooses the algorithm and it rarely changes; with State, the state objects move the context from one state to the next as events arrive.
Model answer
Both patterns put behavior behind an interface and let a context delegate to the current implementation. The difference is who switches it, and why:
- Strategy: the client picks an algorithm (standard vs express shipping, a sorting rule) and passes it in. The strategies don’t know about each other, and the choice usually doesn’t change during the object’s life.
- State: the context’s behavior depends on its current state, and the states themselves decide the next one as events arrive (a document goes Draft → In review → Published; a player goes loading → playing → paused). Each state object handles every event, and actions not allowed in a state are refused there.
A quick test: if your “strategies” start returning or installing the next strategy, you’ve built a state machine. In modern code, many state machines are an enum or sealed type with one transition function (state, event) → next state, which is the State pattern without a class per state.
What they're looking for
The shared structure, who controls switching, and a concrete example of each (shipping cost strategies vs a document or player state machine).
Common mistakes
- Saying they're the same pattern.
- Describing State only as an enum without transition rules.
- Not mentioning that impossible combinations of flags are what State removes.