Design an ATM system. What are the key classes and interactions?

Direct Answer

An ATM system has core classes: ATM (Singleton controller), Card, Account, BankServer (external verification), CashDispenser (manages denominations), CardReader, and ATMState hierarchy (State pattern). The ATM flows through states: Idle → CardInserted → Authenticated → SelectAction → Processing → DispensingCash, with each state handling only valid transitions.

Deep Dive & Architecture

ATM aggregate and device adapters

The ATM coordinates one customer session. Hardware-facing classes such as CardReader, Keypad, Screen, and CashDispenser each hide one device. A BankGateway verifies the card and asks the bank to authorize a debit; the ATM should not own the account balance or PIN.

State controls which action is legal

The session moves through states such as Idle, CardInserted, Authenticated, and Dispensing. In Idle, inserting a card is valid but withdrawing is not. Each state handles the allowed action and returns or installs the next state, which avoids a large controller full of phase flags.

A withdrawal crosses several boundaries

For a withdrawal of 2,000, the ATM authenticates the session, asks the bank to authorize the amount, asks the dispenser to prepare an exact note plan, dispenses only after both checks succeed, records the outcome, and then clears the session. Failure paths must also be explicit: insufficient account funds, insufficient notes, a device error, timeout, or cancellation. One ATM object can represent one physical machine through normal application wiring; a global Singleton is not what protects its state.

Code Example

interface ATMState {
    void insertCard(ATM atm, Card card);
    void enterPin(ATM atm, char[] pin);
    void withdraw(ATM atm, Money amount);
}

class ATM {
    private ATMState state = new IdleState();
    private final BankGateway bank;
    private final CashDispenser dispenser;

    ATM(BankGateway bank, CashDispenser dispenser) {
        this.bank = bank;
        this.dispenser = dispenser;
    }

    void transitionTo(ATMState next) { state = next; }
    void insertCard(Card card) { state.insertCard(this, card); }
    void withdraw(Money amount) { state.withdraw(this, amount); }
    BankGateway bank() { return bank; }
    CashDispenser dispenser() { return dispenser; }
}

class IdleState implements ATMState {
    public void insertCard(ATM atm, Card card) {
        atm.transitionTo(new CardInsertedState(card));
    }
    public void enterPin(ATM atm, char[] pin) { throw new IllegalStateException("insert card first"); }
    public void withdraw(ATM atm, Money amount) { throw new IllegalStateException("authenticate first"); }
}

Application configuration creates one aggregate for each physical machine; the class does not hide a global Singleton.

Common Mistakes & Pitfalls

• Giant if-else on the phase — if (phase == AUTH) ... everywhere. That is the State pattern done badly; make each phase a class.
• One God ATM class doing verification, dispensing, and UI. Split out BankServer and CashDispenser (SRP).
• Storing the PIN — verify via BankServer and discard immediately; never keep it.
• Ignoring invalid transitions — withdrawing before authentication must fail loudly, not silently.