State
State delegates behavior to the current lifecycle state. A transition changes what the context is allowed to do next, rather than merely changing a status label.
What you’ll understand
- State delegates behavior to the current lifecycle state. A transition changes what the context is allowed to do next, rather than merely changing a status label.
- A transition table centralizes permitted event-state pairs and leaves state unchanged for invalid events.
- Evaluate the tradeoff: A table is enough for small lifecycles; state objects help when each state owns substantial behavior. Define invalid events explicitly rather than relying on incidental exceptions.
Useful first: Classes and Objects
The idea and when to recognize it
State delegates behavior to the current lifecycle state. A transition changes what the context is allowed to do next, rather than merely changing a status label.
- Requirement: An order can be paid once and shipped only after payment.
- Change to anticipate: Reject shipping before payment and repeated payment while retaining the last valid state.
- Design goal: A transition table centralizes permitted event-state pairs and leaves state unchanged for invalid events.
Start with the concrete problem
An order can be paid once and shipped only after payment.
Reject shipping before payment and repeated payment while retaining the last valid state.
| Direct implementation | Revised design |
|---|---|
| Setting state from the event name allows impossible transitions such as shipping an unpaid order. | A transition table centralizes permitted event-state pairs and leaves state unchanged for invalid events. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | A table is enough for small lifecycles; state objects help when each state owns substantial behavior. Define invalid events explicitly rather than relying on incidental exceptions. |
Responsibilities and contracts
A transition table centralizes permitted event-state pairs and leaves state unchanged for invalid events.
- Order: Owns current lifecycle state. Public operations: handle(event)
- New: Allows payment. Public operations: pay → paid
- Paid: Allows shipment. Public operations: ship → shipped
- Shipped: Terminal state. Public operations: reject further changes
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A connection can permit send only after a successful handshake and reject it after close.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
A table is enough for small lifecycles; state objects help when each state owns substantial behavior. Define invalid events explicitly rather than relying on incidental exceptions.
Common mistake: Setting state from the event name allows impossible transitions such as shipping an unpaid order.
- Explain the choice: A transition table centralizes permitted event-state pairs and leaves state unchanged for invalid events.
- Challenge your choice: A table is enough for small lifecycles; state objects help when each state owns substantial behavior. Define invalid events explicitly rather than relying on incidental exceptions.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…