State Design pattern - Real time example [ATM]

Master Practical Java Architecture & Design Patterns!

Subscribe to Ram N Java for clean coding tutorials, GoF design patterns, and real-world system implementations!

🔔 Subscribe to Ram N Java

The Real-Time ATM Challenge

An Automated Teller Machine (ATM) is an intuitive real-world scenario to understand the State Design Pattern. An ATM reacts completely differently to the exact same user action depending on its current operational state:

• No Card State: Pressing PIN numbers or requesting cash has no effect—the machine waits for an inserted card.
• Has Card State: The card is retained while prompting for PIN entry, rejecting multiple card insertions.
• Authorized / Correct PIN State: Cash withdrawals and balance inquiries are enabled.
• No Cash State: Financial dispensing is disabled, prompting service alerts or maintenance.

Implementing these state transitions using conventional nested if-else or switch-case statements leads to tangled, fragile code that is prone to errors whenever new banking operations or states are introduced.

Architecture of the State Pattern Solution

The State Design Pattern solves this by encapsulating each distinct machine state into its own class and delegating behavior to the active state:

• State Interface: Outlines key operations across the ATM lifecycle, including insertCard(), ejectCard(), insertPin(), and requestCash().
• Concrete State Classes: Classes such as NoCard, HasCard, HasPin, and NoCash implement specific behaviors for their respective states and manage transitions to the next state.
• Context Class (ATMMachine): Manages the machine's hardware state (such as cash inventory), holds a reference to the current state object, and delegates user actions directly to it.

Key Architectural Benefits

Applying the State pattern to real-world ATM modeling brings substantial design benefits:

• Elimination of Nested Conditionals: Replaces messy conditional branches with clean, polymorphic execution.
• Single Responsibility Principle: Keeps the validation and business logic for each operational phase isolated in dedicated classes.
• Open/Closed Principle: Adding new states (e.g., MaintenanceMode, CardStuckState) does not require altering existing state classes.

Related Tutorials from Ram N Java

• 👉 State Design Pattern in Action: ATM Use Case Implementation
• 👉 State Design Pattern Explained: Vending Machine Real-Time Example
• 👉 State Design Pattern Practical Example: LED TV Implementation

---

Click here to watch in Youtube : https://www.youtube.com/watch?v=ELS2v7pHLgI

Click the below Image to Enlarge

State Design pattern - Real time example [ATM]