State: Behavior Based on State
Allow an object to alter its behavior when its internal state changes — replace state conditionals with polymorphic state objects.
Why this matters
An Order moves through: Pending → Processing → Shipped → Delivered → Cancelled. Without the State pattern, every method on Order (ship(), cancel(), deliver()) contains the same long status-checking conditional. Add a new state like "Returning" and you must edit every method. With the State pattern, each state is a class that owns its valid transitions. Adding "Returning" means one new class — existing state classes are untouched.
State machines at scale
For simple cases with a handful of states, the pattern is self-contained. For complex workflows with dozens of states, consider a dedicated state-machine library (XState for TypeScript, transitions for Python). These libraries add guard conditions, entry/exit actions, and visualization — the State pattern is still the conceptual foundation.
💡Key takeaway
When you see the same if status == X block repeated in every method of a class, extract each status into a State object — transitions become self-contained and new states require no edits to existing code.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: When you see the same `if status == X` block repeated in every method of a class, the class needs a State pattern.
✗ Your version