Design an ATM

Problem Object-oriented design of an ATM supporting withdrawal and deposit; follow-up (see follow-ups): cards linked to multiple accounts require account selection before any transaction.

Requirements

• Card authentication (insert/tap + PIN), balance inquiry, cash withdrawal (dispense denominations, debit account), cash/cheque deposit, receipt, session end/card eject; hardware faults and insufficient funds/cash handled cleanly.

Core design

• STATE machine as the spine: Idle → CardInserted → Authenticated → TransactionSelection → (Withdrawing | Depositing) → Complete/Eject; each state a class permitting only legal operations.
• Classes: ATM (facade holding state + hardware), CardReader, Screen/Keypad, CashDispenser (denomination inventory; dispense via greedy/DP over available notes, fail if unmakeable), DepositSlot, Card(number, linked accounts), Account, BankService interface (authorize PIN, post transactions — the ATM never owns balances; it talks to the bank), Transaction hierarchy (Withdrawal/Deposit/BalanceInquiry — command pattern).
• Session object scoping authenticated card + selected account, cleared on eject/timeout.

Discussion points

• Atomicity: dispense-then-debit vs debit-then-dispense — two-phase with reversal on hardware failure (never lose money silently); idempotent posting to BankService.
• Concurrency: cash inventory under simultaneous sessions (per-ATM serial), daily limits, timeout auto-cancel.
• Extensibility probes: new transaction types (mini-statement, transfers) via the command hierarchy; multi-currency cassettes; accessibility modes.