5 problems are:
- ATM
- Vending Machine
- Elevator
- Traffic Control
- Coffee Vending Machine
Problem-wise patterns
| Problem | Main patterns |
|---|---|
| ATM | State, Chain of Responsibility, Singleton |
| Vending Machine | State machine, Singleton, Facade |
| Elevator | Strategy, Observer, Singleton |
| Traffic Control | State, Strategy, Observer, Singleton |
| Coffee Vending Machine | State, Singleton, Facade, Template Method, Decorator, Factory |
Short notes
1) ATM
- State for idle, card inserted, authenticated
- Chain of Responsibility for cash dispensing by denominations
- Singleton because one controller manages one physical ATM
2) Vending Machine
- State for machine lifecycle
- Singleton for one shared instance
- Facade to hide internal inventory and state handling
3) Elevator
- Strategy for dispatch algorithms
- Observer for display updates and notifications
- Singleton for one building-level controller
4) Traffic Control
- State for signal phases like green, yellow, red
- Strategy for timing or switching policies
- Observer for notifying connected components
- Singleton for centralized controller
5) Coffee Vending Machine
- State for user flow
- Singleton for one machine
- Facade for simple API
- Template Method for coffee preparation steps
- Decorator for add-ons
- Factory for creating coffee types
Perfect. Here is a compact interview table for the 5 Managing States problems.
1) ATM
| Pattern | Why it is used |
|---|---|
| State | Different behavior in IDLE, CARD_INSERTED, AUTHENTICATED |
| Chain of Responsibility | Dispense cash using 50, 10 handlers |
| Singleton | One physical ATM, one controller instance |
30-second answer:
ATM is a state-driven system because valid actions depend on whether the card is inserted and whether the user is authenticated. State pattern keeps those rules in separate classes. Cash dispensing uses Chain of Responsibility to try denominations in order. Singleton ensures one controller manages the machine consistently.
2) Vending Machine
| Pattern | Why it is used |
|---|---|
| State | Actions depend on machine state, like waiting, money inserted, item selected |
| Singleton | One machine instance represents one physical vending machine |
| Facade | Public API stays simple while inventory and state logic stay hidden |
30-second answer:
Vending Machine is a classic State pattern problem because each user action behaves differently depending on the machine state. Singleton fits because the machine represents one real device. Facade helps expose a clean interface like insert coin, select item, and dispense without leaking internal complexity.
3) Elevator
| Pattern | Why it is used |
|---|---|
| Strategy | Different dispatch algorithms like nearest elevator or zone-based routing |
| Observer | Displays and dashboards update when elevator state changes |
| Singleton | One building-wide coordinator manages all elevators |
30-second answer:
Elevator system is usually driven by Strategy because the dispatch logic can change without affecting the rest of the system. Observer lets floor displays and logs react to state changes. Singleton makes sense for the central controller that coordinates all elevators.
4) Traffic Control
| Pattern | Why it is used |
|---|---|
| State | Traffic light cycles through red, yellow, green |
| Strategy | Different timing policies for normal hours, peak hours, emergency mode |
| Observer | Cars, timers, or monitoring systems can react to signal changes |
| Singleton | One intersection controller manages the signal sequence |
30-second answer:
Traffic control is a state machine because the light transitions between red, yellow, and green. Strategy is useful if timing rules vary by context. Observer helps notify connected components when the signal changes. Singleton fits a centralized intersection controller.
5) Coffee Vending Machine
| Pattern | Why it is used |
|---|---|
| State | Machine flow changes across waiting, selecting, paying, dispensing |
| Singleton | One machine instance with shared inventory |
| Facade | Simple user-facing API hides internal steps |
| Template Method | Brewing steps are fixed, but some steps vary by coffee type |
| Decorator | Add toppings or extras dynamically |
| Factory | Create coffee variants centrally |
30-second answer:
Coffee Vending Machine combines multiple patterns. State handles the user interaction flow, Singleton models the one machine, Facade simplifies the interface, Template Method fixes the brewing steps, Decorator adds toppings, and Factory creates the correct coffee type.
Super quick memory map
- ATM = State + Chain + Singleton
- Vending Machine = State + Singleton + Facade
- Elevator = Strategy + Observer + Singleton
- Traffic Control = State + Strategy + Observer + Singleton
- Coffee Vending Machine = State + Singleton + Facade + Template + Decorator + Factory