Vending Machine
A vending machine coordinates credit, stock, and purchase outcomes through explicit state transitions. A failed selection must preserve both money and inventory until a successful purchase or cancellation.
What you’ll understand
- A vending machine coordinates credit, stock, and purchase outcomes through explicit state transitions. A failed selection must preserve both money and inventory until a successful purchase or cancellation.
- VendingMachine validates each action before changing stock or credit and reports the outcome of every transition.
- Evaluate the tradeoff: This model excludes coin denomination constraints, hardware failures, and persistent recovery. A real dispenser needs an explicit protocol for a charged-but-not-dispensed failure rather than assuming the physical action always succeeds.
Useful first: Classes and Objects
The idea and when to recognize it
A vending machine coordinates credit, stock, and purchase outcomes through explicit state transitions. A failed selection must preserve both money and inventory until a successful purchase or cancellation.
- Requirement: A machine sells one product for an integer price. Customers insert credit, select the product, or cancel.
- Change to anticipate: Reject insufficient credit and sold-out purchases, dispense once on success, return change, and refund all remaining credit on cancellation.
- Design goal: VendingMachine validates each action before changing stock or credit and reports the outcome of every transition.
Start with the concrete problem
A machine sells one product for an integer price. Customers insert credit, select the product, or cancel.
Reject insufficient credit and sold-out purchases, dispense once on success, return change, and refund all remaining credit on cancellation.
| Direct implementation | Revised design |
|---|---|
| Subtracting price before validating credit and stock can create negative credit or dispense nonexistent inventory. | VendingMachine validates each action before changing stock or credit and reports the outcome of every transition. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | This model excludes coin denomination constraints, hardware failures, and persistent recovery. A real dispenser needs an explicit protocol for a charged-but-not-dispensed failure rather than assuming the physical action always succeeds. |
Scope and extension questions
This is a deterministic single-process model. Persistence, authentication, real network calls, and distributed coordination are outside this exercise.
- Which public operation must be atomic if two callers act at once?
- What data must be saved to recover after a restart?
- How would you change one policy without rewriting the core state transitions?
Responsibilities and contracts
VendingMachine validates each action before changing stock or credit and reports the outcome of every transition.
- VendingMachine: Owns credit and action rules. Public operations: insert(amount), buy(), cancel()
- Inventory: Tracks available units. Public operations: stock
- Credit: Tracks integer monetary units. Public operations: amount
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 ticket kiosk follows a similar credit-reservation-confirmation flow, with failure recovery around ticket printing.
- 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
This model excludes coin denomination constraints, hardware failures, and persistent recovery. A real dispenser needs an explicit protocol for a charged-but-not-dispensed failure rather than assuming the physical action always succeeds.
Common mistake: Subtracting price before validating credit and stock can create negative credit or dispense nonexistent inventory.
- Explain the choice: VendingMachine validates each action before changing stock or credit and reports the outcome of every transition.
- Challenge your choice: This model excludes coin denomination constraints, hardware failures, and persistent recovery. A real dispenser needs an explicit protocol for a charged-but-not-dispensed failure rather than assuming the physical action always succeeds.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…