DEV Community: NOOB

LLD:15-Order Management System

NOOB — Sat, 27 Jun 2026 14:06:44 +0000

Order Management System - State Pattern Implementation

This is an implementation of the State design pattern for an e-commerce Order Management System. By utilizing this pattern, an order dictates its own lifecycle (Created, Paid, Shipped, Delivered) and strictly enforces business rules without relying on messy if/else or switch statements evaluating an "order status" flag.

Problem Statement

Building the backend flow for an e-commerce order that transitions through four sequential states: Created, Paid, Shipped, and Delivered. The challenge is ensuring that illegal operations—like attempting to ship an unpaid order or paying for an order that has already been delivered—are gracefully blocked based on the current state.

Key Challenge:

If ship() is called in the Created state → "ERROR: Cannot ship an unpaid order."
The happy path must flow perfectly: Created -> pay() -> Paid -> ship() -> Shipped -> deliver() -> Delivered.
The Context (Order) should not contain the validation logic; the states themselves must handle their own localized rules and transitions.

Class Diagram

                            +----------------------+
                            |    OrderManagement   | <-------------------+
                            +----------------------+                     |
                            | - currentState       |                     |
                            +----------------------+                     |
                            | + setState()         |                     |
                            | + pay()              |                     |
                            | + ship()             |                     |
                            | + deliver()          |                     |
                            +----------+-----------+                     |
                                       |                                 |
                                       | (Delegates to)                  |
                                       v                                 |
                            +----------------------+                     |
                            |        State         |                     |
                            |      (Interface)     |                     |
                            +----------------------+                     |
                            | + pay()              |                     |
                            | + ship()             |                     |
                            | + deliver()          |                     |
                            +----------+-----------+                     |
                                       ^                                 |
                                       | (Implements)                    |
            +--------------------------+--------------------------+      |
            |                          |                          |      |
 +----------+----------+    +----------+----------+    +----------+------+-+
 |    CreatedState     |    |      PaidState      |    |   ShippedState    |
 +---------------------+    +---------------------+    +-------------------+
 | - orderManagement   |--->| - orderManagement   |--->| - orderManagement |
 | + pay()             |    | + pay()             |    | + pay()           |
 | + ship()            |    | + ship()            |    | + ship()          |
 | + deliver()         |    | + deliver()         |    | + deliver()       |
 +---------------------+    +---------------------+    +-------------------+
              (And DeliveredState follows the exact same pattern!)

Implementation

package state.orderManagementSystem;

public class OrderManagementSystem {

    /**
     * 1. The State Interface
     * Defines the core actions that can be performed on an order.
     */
    interface State {
        void pay();
        void ship();
        void deliver();
    }

    /**
     * 2. The Context (OrderManagement)
     * Maintains a reference to the current state and delegates actions.
     */
    static class OrderManagement {
        State createdState;
        State paidState;
        State shippedState;
        State deliveredState;

        State currentState;

        public OrderManagement() {
            // Pass 'this' so states can talk back to the Context to change states
            createdState = new CreatedState(this);
            paidState = new PaidState(this);
            shippedState = new ShippedState(this);
            deliveredState = new DeliveredState(this);

            // Order starts in the Created state
            currentState = createdState;
        }

        public void setState(State state) {
            this.currentState = state;
        }

        public void pay() {
            currentState.pay();
        }

        public void ship() {
            currentState.ship();
        }

        public void deliver() {
            currentState.deliver();
        }
    }

    /**
     * 3. Concrete State: Created
     * Order is placed, waiting for payment.
     */
    static class CreatedState implements State {
        private final OrderManagement orderManagement;

        public CreatedState(OrderManagement orderManagement) {
            this.orderManagement = orderManagement;
        }

        @Override
        public void pay() {
            System.out.println("Payment successful! Order is now Paid.");
            orderManagement.setState(orderManagement.paidState); // Transition
        }

        @Override
        public void ship() {
            System.out.println("ERROR: Cannot ship an unpaid order.");
        }

        @Override
        public void deliver() {
            System.out.println("ERROR: Cannot deliver an unpaid order.");
        }
    }

    /**
     * 3. Concrete State: Paid
     * Payment is successful, waiting for dispatch.
     */
    static class PaidState implements State {
        private final OrderManagement orderManagement;

        public PaidState(OrderManagement orderManagement) {
            this.orderManagement = orderManagement;
        }

        @Override
        public void pay() {
            System.out.println("ERROR: Order is already paid.");
        }

        @Override
        public void ship() {
            System.out.println("Order dispatched! Order is now Shipped.");
            orderManagement.setState(orderManagement.shippedState); // Transition
        }

        @Override
        public void deliver() {
            System.out.println("ERROR: Cannot deliver an order that hasn't shipped.");
        }
    }

    /**
     * 3. Concrete State: Shipped
     * The order is on the truck, waiting for delivery.
     */
    static class ShippedState implements State {
        private final OrderManagement orderManagement;

        public ShippedState(OrderManagement orderManagement) {
            this.orderManagement = orderManagement;
        }

        @Override
        public void pay() {
            System.out.println("ERROR: Order is already paid.");
        }

        @Override
        public void ship() {
            System.out.println("ERROR: Order is already shipped.");
        }

        @Override
        public void deliver() {
            System.out.println("Order dropped off! Order is now Delivered.");
            orderManagement.setState(orderManagement.deliveredState); // Transition
        }
    }

    /**
     * 3. Concrete State: Delivered
     * The order is complete. No further actions allowed.
     */
    static class DeliveredState implements State {
        private final OrderManagement orderManagement;

        public DeliveredState(OrderManagement orderManagement) {
            this.orderManagement = orderManagement;
        }

        @Override
        public void pay() {
            System.out.println("ERROR: Order is already complete.");
        }

        @Override
        public void ship() {
            System.out.println("ERROR: Order is already complete.");
        }

        @Override
        public void deliver() {
            System.out.println("ERROR: Order is already delivered.");
        }
    }

    /**
     * 4. Main Driver
     */
    public static void main(String[] args) {
        System.out.println("---- Order Management System ----");

        OrderManagement order = new OrderManagement();

        System.out.println("\n--- Attempt 1: Trying to ship before paying ---");
        order.ship();

        System.out.println("\n--- Attempt 2: Happy Path ---");
        order.pay();
        order.ship();
        order.deliver();

        System.out.println("\n--- Attempt 3: Action after completion ---");
        order.pay();
    }
}

Key Features

Strict Business Logic Pipeline: The pattern perfectly models a one-way sequential pipeline (Created -> Paid -> Shipped -> Delivered) where skipping steps is inherently impossible.
Localized Error Handling: Instead of the Context checking if (status == CREATED), the CreatedState naturally knows how to reject ship() and deliver() requests.
No Complex Conditionals: Adding a new step (e.g., RefundedState) requires creating a new class rather than modifying massive switch blocks in the core OrderManagement logic.
Self-Contained Transitions: Each state is responsible for handing the baton to the next logical state via orderManagement.setState().

How It Works

Initialization: When OrderManagement is instantiated, it initializes all possible states and defaults its currentState to CreatedState.
Invalid Action: If the client calls ship() while in CreatedState, the request is passed to CreatedState.ship(), which outputs an error and prevents any transition.
Happy Path Transition: Calling pay() on CreatedState executes the payment logic and transitions the context to PaidState. Subsequent calls to ship() and deliver() cascade through the remaining states.
Terminal State: Once it reaches DeliveredState, all core actions (pay, ship, deliver) act as dead ends, preventing further manipulation of a completed order.

Sample Output

---- Order Management System ----

--- Attempt 1: Trying to ship before paying ---
ERROR: Cannot ship an unpaid order.

--- Attempt 2: Happy Path ---
Payment successful! Order is now Paid.
Order dispatched! Order is now Shipped.
Order dropped off! Order is now Delivered.

--- Attempt 3: Action after completion ---
ERROR: Order is already complete.

LLD:14-ATM Machine System

NOOB — Fri, 26 Jun 2026 16:47:27 +0000

ATM Machine System - State Pattern Implementation

This is an implementation of the State design pattern for an ATM Machine. By utilizing this pattern, the ATM can alter its behavior based on its internal state (Idle, Card Inserted, PIN Entered, etc.) without relying on complex, nested if/else logic.

Problem Statement

Building the software for an ATM that transitions between distinct operational states: Idle, Card Inserted, PIN Entered, Withdrawing Cash, and Out of Cash. The system must restrict invalid operations based on the current state.

Key Challenge:

If a user tries to withdrawCash() in the Idle state, it should throw an error or prompt the user to insert their card first.
The happy path must flow sequentially: Idle -> insertCard() -> Card Inserted -> enterPin() -> PIN Entered -> withdrawCash() -> Cash Dispensed (which automatically returns the machine to Idle).

Class Diagram

(Note: The diagram has been updated from your prompt to reflect the ATM domain rather than an Order Processing system.)

                            +----------------------+
                            |      ATMMachine      | <-------------------+
                            +----------------------+                     |
                            | - currentState       |                     |
                            | - totalCash          |                     |
                            +----------------------+                     |
                            | + setState()         |                     |
                            | + insertCard()       |                     |
                            | + enterPin()         |                     |
                            | + withdrawCash()     |                     |
                            +----------+-----------+                     |
                                       |                                 |
                                       | (Delegates to)                  |
                                       v                                 |
                            +----------------------+                     |
                            |        State         |                     |
                            |      (Interface)     |                     |
                            +----------------------+                     |
                            | + insertCard()       |                     |
                            | + enterPin()         |                     |
                            | + withdrawCash()     |                     |
                            +----------+-----------+                     |
                                       ^                                 |
                                       | (Implements)                    |
            +--------------------------+--------------------------+      |
            |                          |                          |      |
 +----------+----------+    +----------+----------+    +----------+------+-+
 |      IdleState      |    |   InsertCardState   |    |   EnterPinState   |
 +---------------------+    +---------------------+    +-------------------+
 | - atmMachine        |--->| - atmMachine        |--->| - atmMachine      |
 | + insertCard()      |    | + insertCard()      |    | + insertCard()    |
 | + enterPin()        |    | + enterPin()        |    | + enterPin()      |
 | + withdrawCash()    |    | + withdrawCash()    |    | + withdrawCash()  |
 +---------------------+    +---------------------+    +-------------------+

Implementation

(Note: I updated IdealState to IdleState to align with the standard naming convention for resting states in finite-state machines).

package state.atmmachine;

public class ATMMachineSystem {

    /**
     * State Interface.
     * Defines the common actions a user can attempt at the ATM.
     */
    interface State {
        void insertCard();
        void enterPin();
        void withdrawCash(int cash);
    }

    /**
     * Context Class.
     * Maintains a reference to the current state and delegates user actions to it.
     */
    static class ATMMachine {
        State idleState;
        State insertCardState;
        State enterPinState;
        State withdrawCashState;
        State outOfCashState;

        State currentState;
        int totalCash;

        public ATMMachine(int totalCash) {
            idleState = new IdleState(this);
            insertCardState = new InsertCardState(this);
            enterPinState = new EnterPinState(this);
            withdrawCashState = new WithdrawCashState(this);
            outOfCashState = new OutOfCashState(this);

            this.totalCash = totalCash;
            if (totalCash > 0) {
                currentState = idleState;
            } else {
                currentState = outOfCashState;
            }
        }

        public void setState(State state) {
            this.currentState = state;
        }

        public void insertCard() {
            currentState.insertCard();
        }

        public void enterPin() {
            currentState.enterPin();
        }

        public void withdrawCash(int cash) {
            currentState.withdrawCash(cash);
        }
    }

    /**
     * Concrete State: Waiting for a user.
     */
    static class IdleState implements State {
        private final ATMMachine atmMachine;

        public IdleState(ATMMachine atmMachine) {
            this.atmMachine = atmMachine;
        }

        @Override
        public void insertCard() {
            System.out.println("Insert Card to withdraw money.");
            atmMachine.setState(atmMachine.insertCardState);
        }

        @Override
        public void enterPin() {
            System.out.println("ERROR: Insert Card first!");
        }

        @Override
        public void withdrawCash(int cash) {
            System.out.println("ERROR: Enter pin first!");
        }
    }

    /**
     * Concrete State: Card is in, waiting for authentication.
     */
    static class InsertCardState implements State {
        private final ATMMachine atmMachine;

        public InsertCardState(ATMMachine atmMachine) {
            this.atmMachine = atmMachine;
        }

        @Override
        public void insertCard() {
            System.out.println("ERROR: Card is already inserted!");
        }

        @Override
        public void enterPin() {
            System.out.println("Enter pin to withdraw cash!");
            atmMachine.setState(atmMachine.enterPinState);
        }

        @Override
        public void withdrawCash(int cash) {
            System.out.println("ERROR: Enter pin to withdraw cash!");
        }
    }

    /**
     * Concrete State: PIN verified, waiting for amount.
     */
    static class EnterPinState implements State {
        private final ATMMachine atmMachine;

        public EnterPinState(ATMMachine atmMachine) {
            this.atmMachine = atmMachine;
        }

        @Override
        public void insertCard() {
            System.out.println("ERROR: Card is already inserted!");
        }

        @Override
        public void enterPin() {
            System.out.println("ERROR: Pin is already inserted");
        }

        @Override
        public void withdrawCash(int cash) {
            System.out.println("Cash is here, please collect!");
            atmMachine.setState(atmMachine.withdrawCashState);
            atmMachine.withdrawCash(cash); // Auto-transitions and dispenses
        }
    }

    /**
     * Concrete State: Dispensing logic and balance checking.
     */
    static class WithdrawCashState implements State {
        private final ATMMachine atmMachine;

        public WithdrawCashState(ATMMachine atmMachine) {
            this.atmMachine = atmMachine;
        }

        @Override
        public void insertCard() {
            System.out.println("ERROR: Card is already inserted!");
        }

        @Override
        public void enterPin() {
            System.out.println("ERROR: Pin is already inserted");
        }

        @Override
        public void withdrawCash(int cash) {
            if (atmMachine.totalCash >= cash) {
                atmMachine.totalCash -= cash;
                System.out.println("Success! Dispensing $" + cash + ". Please collect your cash.");
                System.out.println("Remaining ATM balance: $" + atmMachine.totalCash);

                if (atmMachine.totalCash > 0) {
                    atmMachine.setState(atmMachine.idleState);
                } else {
                    System.out.println("ATM Machine is out of cash!");
                    atmMachine.setState(atmMachine.outOfCashState);
                }
            } else {
                System.out.println("ERROR: Insufficient funds in ATM.");
                atmMachine.setState(atmMachine.idleState);
            }
        }
    }

    /**
     * Concrete State: Machine is empty, denying all interactions.
     */
    static class OutOfCashState implements State {
        private final ATMMachine atmMachine;

        public OutOfCashState(ATMMachine atmMachine) {
            this.atmMachine = atmMachine;
        }

        @Override
        public void insertCard() {
            System.out.println("ERROR, Machine is out of cash!");
        }

        @Override
        public void enterPin() {
            System.out.println("ERROR, Machine is out of cash!");
        }

        @Override
        public void withdrawCash(int cash) {
            System.out.println("ERROR, Machine is out of cash!");
        }
    }

    /**
     * Main driver method.
     */
    public static void main(String[] args) {
        System.out.println("---- ATM Machine Booting UP ----");

        ATMMachine atmMachine = new ATMMachine(50);

        System.out.println("\n---- Attempt 1: Direct withdrawing cash ----");
        atmMachine.withdrawCash(30);

        System.out.println("\n---- Attempt 2: Happy Path ----");
        atmMachine.insertCard();
        atmMachine.enterPin();
        atmMachine.withdrawCash(30);
    }
}

Key Features

State Interface Integration: Enforces a rigid contract (insertCard, enterPin, withdrawCash) that all machine states must implement, preventing unhandled states.
Internal Transitions: States control their own routing to the next logical state by calling atmMachine.setState().
Validation-First: The machine organically defends against sequence breaking (e.g., trying to withdraw cash without providing a PIN) by returning context-aware error messages depending on the current active state.
Auto-Delegation: The ATMMachine class remains incredibly clean; its methods are merely wrappers that forward instructions to whatever state is currently active.

How It Works

Booting Up: ATMMachine starts with $50. Because it has money, it defaults to the IdleState.
Attempt 1 (Direct Withdrawal): The client attempts withdrawCash(30). The request is routed to IdleState.withdrawCash(), which safely rejects it since no card is present.
Attempt 2 (Happy Path):
- insertCard() transitions the machine to InsertCardState.
- enterPin() transitions the machine to EnterPinState.
- withdrawCash(30) in EnterPinState sets the state to WithdrawCashState and immediately re-triggers withdrawCash(30) to dispense the funds.
- WithdrawCashState decrements the cash, checks the balance, and successfully transitions back to IdleState.

Sample Output

---- ATM Machine Booting UP ----

---- Attempt 1: Direct withdrawing cash ----
ERROR: Enter pin first!

---- Attempt 2: Happy Path ----
Insert Card to withdraw money.
Enter pin to withdraw cash!
Cash is here, please collect!
Success! Dispensing $30. Please collect your cash.
Remaining ATM balance: $20

LLD:13-Vending Machine System

NOOB — Fri, 26 Jun 2026 14:13:56 +0000

Vending Machine System - State Pattern Implementation

This is an implementation of the State design pattern for a vending machine system where the machine changes its behavior based on its internal state, completely eliminating the need for massive if/else conditional blocks.

Problem Statement

Building the software for a Vending Machine that transitions between four distinct states: Idle, Has Money, Dispensing, and Out of Stock. The challenge is ensuring that actions (like inserting money or selecting an item) behave differently depending on the current state, without hardcoding conditional logic into the main machine class.

Key Challenge:

If selectItem() is called in the Idle state → "Please insert money first."
If selectItem() is called in the Has Money state → Transition to dispensing and output "Dispensing your item."
The machine must handle state transitions internally and gracefully reject invalid actions (like inserting money when out of stock).

Class Diagram

                            +----------------------+
                            |    VendingMachine    | <-------------------+
                            +----------------------+                     |
                            | - currentState       |                     |
                            | - inventory          |                     |
                            +----------------------+                     |
                            | + setState()         |                     |
                            | + insertMoney()      |                     |
                            | + selectItem()       |                     |
                            +----------+-----------+                     |
                                       |                                 |
                                       | (Delegates to)                  |
                                       v                                 |
                            +----------------------+                     |
                            |        State         |                     |
                            |      (Interface)     |                     |
                            +----------------------+                     |
                            | + insertMoney()      |                     |
                            | + selectItem()       |                     |
                            | + dispenseItem()     |                     |
                            +----------+-----------+                     |
                                       ^                                 |
                                       | (Implements)                    |
            +--------------------------+--------------------------+      |
            |                          |                          |      |
 +----------+----------+    +----------+----------+    +----------+------+-+
 |      IdleState      |    |    HasMoneyState    |    |  DispensingState  |
 +---------------------+    +---------------------+    +-------------------+
 | - machine           |--->| - machine           |--->| - machine         |
 | + insertMoney()     |    | + insertMoney()     |    | + insertMoney()   |
 +---------------------+    +---------------------+    +-------------------+

Implementation

package state.vendingmachinesystem;

public class VendingMachineSystem {

    /**
     * State Interface.
     * Defines the common actions that can be performed in any state.
     */
    interface State {
        void insertMoney();
        void selectItem();
        void dispenseItem();
    }

    /**
     * Context Class.
     * Maintains a reference to an instance of a State subclass, 
     * which represents the current state of the vending machine.
     */
     static class VendingMachine {
        State idleState;
        State hasMoneyState;
        State dispenseState;
        State outOfStockState;

        State currentState;
        int inventory;

        public VendingMachine(int inventory) {
            // Initialize all possible states
            idleState = new IdleState(this);
            hasMoneyState = new HasMoneyState(this);
            dispenseState = new DispensingState(this);
            outOfStockState = new OutOfStockState(this);

            this.inventory = inventory;
            if (inventory > 0) {
                currentState = idleState;
            } else {
                currentState = outOfStockState;
            }
        }

        public void setState(State state) {
            this.currentState = state;
        }

        // Action delegations to the current state
        public void insertMoney() {
            currentState.insertMoney();
        }

        public void selectItem() {
            currentState.selectItem();
        }

        public void dispenseItem() {
            currentState.dispenseItem();
        }
     }

    /**
     * Concrete State: Waiting for a user to insert money.
     */
     static class IdleState implements State {
        private final VendingMachine machine;

        public IdleState(VendingMachine machine) {
            this.machine = machine;
        }

         @Override
         public void insertMoney() {
             System.out.println("Money inserted. You can now select an item.");
             machine.setState(machine.hasMoneyState);
         }

         @Override
         public void selectItem() {
            System.out.println("ERROR: Please insert money first");
         }

         @Override
         public void dispenseItem() {
            System.out.println("ERROR: Please insert money and select an item");
         }
     }

    /**
     * Concrete State: Money has been inserted, waiting for item selection.
     */
     static class HasMoneyState implements State {
        private final VendingMachine machine;

        public HasMoneyState(VendingMachine machine) {
            this.machine = machine;
        }

         @Override
         public void insertMoney() {
             System.out.println("ERROR: Money is already inserted");
         }

         @Override
         public void selectItem() {
            System.out.println("Item selected! Dispensing your item");
            machine.setState(machine.dispenseState);
            machine.dispenseItem();
         }

         @Override
         public void dispenseItem() {
            System.out.println("ERROR: You need to select an item first");
         }
     }

    /**
     * Concrete State: Currently pushing the item out of the machine.
     */
     static class DispensingState implements State {
         private final VendingMachine machine;

         public DispensingState(VendingMachine machine) {
             this.machine = machine;
         }

         @Override
         public void insertMoney() {
             System.out.println("ERROR: Please wait, dispensing in progress");
         }

         @Override
         public void selectItem() {
             System.out.println("ERROR: Already dispensing");
         }

         @Override
         public void dispenseItem() {
             machine.inventory--;
             System.out.println("Item dispensed! Remaining inventory: " + machine.inventory);

             if (machine.inventory > 0) {
                 machine.setState(machine.idleState);
             } else {
                 System.out.println("Machine is now Out of Stock.");
                 machine.setState(machine.outOfStockState);
             }
         }
     }

    /**
     * Concrete State: Inventory is zero.
     */
     static class OutOfStockState implements State {
         private VendingMachine machine;

         public OutOfStockState(VendingMachine machine) {
             this.machine = machine;
         }

         @Override
         public void insertMoney() {
             System.out.println("ERROR: Machine is out of stock. Returning money.");
         }

         @Override
         public void selectItem() {
             System.out.println("ERROR: Machine is out of stock");
         }

         @Override
         public void dispenseItem() {
             System.out.println("ERROR: Machine is out of stock");
         }
     }

    /**
     * Main driver method.
     * The client interacts with the VendingMachine actions, unaware of 
     * the underlying state transitions happening dynamically.
     */
     public static void main(String[] args) {
        System.out.println("---- Vending Machine Booting Up ----");

        VendingMachine machine = new VendingMachine(1);

        System.out.println("\n---- Attempt 1: Just pressing select ----");
        machine.selectItem();

        System.out.println("\n---- Attempt 2: Happy Path ----");
        machine.insertMoney();
        machine.selectItem();

        System.out.println("\n---- Attempt 3: Out of Stock ----");
        machine.insertMoney();
     }
}

Key Features

State Pattern: Localizes behavior for different states into separate classes.
Eliminates Conditionals: Replaces messy, sprawling if (state == X) statements with polymorphic method calls.
Single Responsibility: Each state class handles only the rules and transitions relevant to its specific context.
Open/Closed Principle: New states (e.g., MaintenanceState) can be added without drastically changing the existing context or other state classes.
Dynamic Transitions: The context (VendingMachine) alters its behavior at runtime as its internal state changes.

How It Works

Interface (State): Dictates all possible interactions a user can have with the machine (insertMoney, selectItem, dispenseItem).
Context (VendingMachine): Holds a reference to the currentState and passes client requests down to whatever state object currently occupies that variable.
Concrete Classes (IdleState, HasMoneyState, etc.): Provide specific implementations of the state logic and trigger the transition to the next state using machine.setState().
Client (main): Just calls standard methods on the Context, blissfully unaware of the internal state swapping.

Sample Output

---- Vending Machine Booting Up ----

---- Attempt 1: Just pressing select ----
ERROR: Please insert money first

---- Attempt 2: Happy Path ----
Money inserted. You can now select an item.
Item selected! Dispensing your item
Item dispensed! Remaining inventory: 0
Machine is now Out of Stock.

---- Attempt 3: Out of Stock ----
ERROR: Machine is out of stock. Returning money.

LLD-12: Logistic Management System

NOOB — Fri, 26 Jun 2026 12:53:20 +0000

Logistic Management System - Factory Pattern Implementation

This is an implementation of the Factory design pattern for a logistics management system where different transport modes are created through a centralized factory, keeping the client code decoupled from concrete transport implementations.

Problem Statement

Building a logistics management system that supports multiple transport modes (Truck, Ship, Airplane). The challenge is to create the right transport object based on the delivery requirement without the client code directly instantiating concrete transport classes.

Key Challenge:

Truck → Delivering cargo by land in a box.
Ship → Delivering cargo by sea in a container.
Airplane → Delivering cargo by air in a cargo hold.
Client must never use new TruckTransport(), new ShipTransport(), etc. directly

Class Diagram

                            +----------------------+
                            |   LogisticsFactory   |
                            +----------------------+
                            | + createTransport()  |
                            +----------+-----------+
                                       |
                                       | (Creates)
                                       v
                            +----------------------+
                            |       Transport      |
                            |      (Interface)     |
                            +----------------------+
                            | + deliver()          |
                            +----------+-----------+
                                       ^
                                       | (Implements)
           +--------------------------+--------------------------+
           |                          |                          |
+----------+----------+    +----------+----------+    +----------+----------+
|        Truck        |    |         Ship        |    |       Airplane      |
+---------------------+    +---------------------+    +---------------------+
| + deliver()         |    | + deliver()         |    | + deliver()         |
+---------------------+    +---------------------+    +---------------------+

Implementation

package factory.logisticmanagementsystem;

public class LogisticManagementSystem {

    /**
     * Enum to define supported transport modes.
     * Ensures type safety and prevents invalid string inputs.
     */
    enum TransportType {
        TRUCK,
        SHIP,
        AIRPLANE
    }

    /**
     * Component Interface.
     * Defines the contract all transport modes must follow.
     */
    interface Transport {
        void deliver();
    }

    /**
     * Concrete Product for Land Delivery.
     */
    static class TruckTransport implements Transport {
        @Override
        public void deliver() {
            System.out.println("Delivering cargo by land in a box.");
        }
    }

    /**
     * Concrete Product for Sea Delivery.
     */
    static class ShipTransport implements Transport {
        @Override
        public void deliver() {
            System.out.println("Delivering cargo by sea in a container.");
        }
    }

    /**
     * Concrete Product for Air Delivery.
     */
    static class AirTransport implements Transport {
        @Override
        public void deliver() {
            System.out.println("Delivering cargo by air in a cargo hold.");
        }
    }

    /**
     * The Factory Class.
     * This is the ONLY place where the new keyword is used to
     * instantiate concrete transport classes.
     * The client remains completely ignorant of which class is created.
     */
    static class TransportFactory {
        public Transport createTransport(TransportType transportType) {
            return switch (transportType) {
                case TRUCK -> new TruckTransport();
                case SHIP -> new ShipTransport();
                case AIRPLANE -> new AirTransport();
                default -> throw new IllegalArgumentException(
                    "Unsupported Transport"
                );
            };
        }
    }

    /**
     * Main driver method.
     * The client only interacts with the Factory and the Transport Interface.
     * It never references TruckTransport, ShipTransport, or AirTransport directly.
     */
    public static void main(String[] args) {
        System.out.println("---- Logistics Management System ----");

        TransportFactory factory = new TransportFactory();

        Transport truck = factory.createTransport(TransportType.TRUCK);
        truck.deliver();

        Transport ship = factory.createTransport(TransportType.SHIP);
        ship.deliver();

        Transport airplane = factory.createTransport(TransportType.AIRPLANE);
        airplane.deliver();
    }
}

Key Features

Factory Pattern: Centralizes transport object creation in one place
Type Safety: Uses Enum for transport types instead of raw strings
Loose Coupling: Client only depends on the Transport interface, never on concrete classes
Single Responsibility: Factory handles creation, concrete classes handle delivery logic
Open/Closed Principle: Add new transport modes without modifying existing code
Extensible: New transport types require only a new class and a new Enum value

How It Works

Interface (Transport): Defines the deliver() contract all transport modes must follow
Concrete Classes: Each class implements its own mode-specific delivery logic
Factory (TransportFactory): Takes a TransportType Enum and returns the right transport object
Client (main): Only talks to the factory and the interface — never touches concrete classes directly

Sample Output

LLD:11-UI Render System

NOOB — Thu, 25 Jun 2026 16:13:59 +0000

UI Render System - Factory Pattern Implementation

This is an implementation of the Factory design pattern for a cross-platform UI framework that renders OS-specific components without the client code needing to know which operating system it's running on.

Problem Statement

Building a UI framework that runs on both Windows and Mac operating systems. The challenge is to render platform-specific UI components while keeping the client code completely decoupled from the underlying OS-specific implementations.

Key Challenge:

Windows Button → [WINDOWS] Rendering a Windows style button.
Mac Button → [MAC] Rendering a Mac style button.
Client code must never use new WindowsButton() or new MacButton() directly
Adding new OS support should not require changes to client code

Class Diagram

                            +----------------------+
                            |      UIFactory       |
                            +----------------------+
                            | + createButton()     |
                            +----------+-----------+
                                       |
                                       | (Creates)
                                       v
                            +----------------------+
                            |        Button        |
                            |      (Interface)     |
                            +----------------------+
                            | + render()           |
                            +----------+-----------+
                                       ^
                                       | (Implements)
                      +----------------+----------------+
                      |                                 |
           +----------+----------+           +----------+----------+
           |    WindowsButton    |           |       MacButton     |
           +---------------------+           +---------------------+
           | + render()          |           | + render()          |
           +---------------------+           +---------------------+

Implementation

package factory.uirendersystem;

public class UIRenderSystem {

    /**
     * Enum to define supported operating systems.
     * Ensures type safety and prevents invalid string inputs.
     */
    enum OperatingSystem {
        WINDOWS,
        MAC
    }

    /**
     * Component Interface.
     * Defines the contract all platform-specific buttons must follow.
     */
    interface Button {
        void render();
    }

    /**
     * Concrete Product for Windows.
     * Renders a Windows-style button.
     */
    static class WindowsButton implements Button {
        @Override
        public void render() {
            System.out.println("[WINDOWS] Rendering a Windows style button.");
        }
    }

    /**
     * Concrete Product for Mac.
     * Renders a Mac-style button.
     */
    static class MacButton implements Button {
        @Override
        public void render() {
            System.out.println("[MAC] Rendering a Mac style button.");
        }
    }

    /**
     * The Factory Class.
     * This is the ONLY place where the new keyword is used to
     * instantiate concrete button classes.
     * The client remains completely ignorant of which class is created.
     */
    static class UIFactory {
        public Button createButton(OperatingSystem operatingSystem) {
            return switch (operatingSystem) {
                case WINDOWS -> new WindowsButton();
                case MAC -> new MacButton();
                default -> throw new IllegalArgumentException(
                    "Unsupported OS Type"
                );
            };
        }
    }

    /**
     * Main driver method.
     * The client only interacts with the Factory and the Button Interface.
     * It never references WindowsButton or MacButton directly.
     */
    public static void main(String[] args) {
        System.out.println("---- Cross-Platform UI Library ----");

        UIFactory uiFactory = new UIFactory();

        Button windowsBtn = uiFactory.createButton(OperatingSystem.WINDOWS);
        windowsBtn.render();

        Button macBtn = uiFactory.createButton(OperatingSystem.MAC);
        macBtn.render();
    }
}

Key Features

Factory Pattern: Centralizes platform-specific object creation in one place
Type Safety: Uses Enum for OS types instead of raw strings
Loose Coupling: Client only depends on the Button interface, never on concrete classes
Platform Independence: Client code works identically regardless of OS
Open/Closed Principle: Add new OS support without modifying existing code
Extensible: New platforms require only a new class and a new Enum value

How It Works

Interface (Button): Defines the render() contract all platform buttons must follow
Concrete Classes: Each class implements its own OS-specific rendering logic
Factory (UIFactory): Takes an OperatingSystem Enum and returns the right button object
Client (main): Only talks to the factory and the interface — never touches concrete classes directly

Sample Output

LLD-10: Notification System

NOOB — Thu, 25 Jun 2026 15:21:51 +0000

Notification System - Factory Pattern Implementation

This is an implementation of the Factory design pattern for a multi-channel notification system where the client remains completely decoupled from the concrete notification classes being created.

Problem Statement

Building a fintech alert system that can send notifications through multiple channels (Email, WhatsApp, Instagram). The challenge is to centralize object creation so the client code never needs to know which concrete class is being instantiated.

Key Challenge:

Support multiple notification channels
Client must remain ignorant of concrete classes
The new keyword should only appear in one place — the Factory
Adding new notification channels should not require changes to client code

Class Diagram

                            +----------------------+
                            | NotificationFactory  |
                            +----------------------+
                            | + getNotification()  |
                            +----------+-----------+
                                       |
                                       | (Creates)
                                       v
                            +----------------------+
                            |     Notification     |
                            |      (Interface)     |
                            +----------------------+
                            | + sendNotification() |
                            +----------+-----------+
                                       ^
                                       | (Implements)
           +--------------------------+--------------------------+
           |                          |                          |
+----------+----------+    +----------+----------+    +----------+----------+
|  EmailNotification  |    | WhatsAppNotification|    |InstagramNotification|
+---------------------+    +---------------------+    +---------------------+
| + sendNotification()|    | + sendNotification()|    | + sendNotification()|
+---------------------+    +---------------------+    +---------------------+

Implementation

package factory.notificationsystem;

public class NotificationSystem {

    /**
     * Enum to define supported notification channels.
     * Ensures type safety and prevents invalid string inputs.
     */
    enum NotificationType {
        EMAIL,
        WHATSAPP,
        INSTAGRAM
    }

    /**
     * Component Interface.
     * Defines the contract all notification channels must follow.
     */
    interface Notification {
        void sendNotification(String notification);
    }

    /**
     * Concrete Class for Email Notifications.
     */
    static class EmailNotification implements Notification {
        @Override
        public void sendNotification(String notification) {
            System.out.println("[NOTIFICATION: EMAIL] " + notification);
        }
    }

    /**
     * Concrete Class for WhatsApp Notifications.
     */
    static class WhatsAppNotification implements Notification {
        @Override
        public void sendNotification(String notification) {
            System.out.println("[NOTIFICATION: WHATSAPP] " + notification);
        }
    }

    /**
     * Concrete Class for Instagram Notifications.
     */
    static class InstagramNotification implements Notification {
        @Override
        public void sendNotification(String notification) {
            System.out.println("[NOTIFICATION: INSTAGRAM] " + notification);
        }
    }

    /**
     * The Factory Class.
     * This is the ONLY place where the new keyword is used to
     * instantiate concrete notification classes.
     * The client remains completely ignorant of which class is created.
     */
    static class NotificationFactory {
        public Notification getNotification(NotificationType notificationType) {
            return switch (notificationType) {
                case EMAIL -> new EmailNotification();
                case WHATSAPP -> new WhatsAppNotification();
                case INSTAGRAM -> new InstagramNotification();
                default -> throw new IllegalArgumentException(
                    "Unsupported Notification Type"
                );
            };
        }
    }

    /**
     * Main driver method.
     * The client only interacts with the Factory and the Interface.
     * It never references EmailNotification, WhatsAppNotification, etc. directly.
     */
    public static void main(String[] args) {
        System.out.println("---- Fintech Alert System ----");

        NotificationFactory notificationFactory = new NotificationFactory();

        Notification emailAlert = notificationFactory.getNotification(
            NotificationType.EMAIL
        );
        emailAlert.sendNotification("Hello from EMAIL");

        Notification whatsAppAlert = notificationFactory.getNotification(
            NotificationType.WHATSAPP
        );
        whatsAppAlert.sendNotification("Hello from WhatsApp");

        Notification instagramAlert = notificationFactory.getNotification(
            NotificationType.INSTAGRAM
        );
        instagramAlert.sendNotification("Hello from Instagram");
    }
}

Key Features

Factory Pattern: Centralizes object creation in a single place
Type Safety: Uses Enum instead of raw strings for notification types
Loose Coupling: Client only depends on the interface, never on concrete classes
Single Responsibility: Factory handles creation, concrete classes handle delivery
Open/Closed Principle: Add new channels without modifying existing code
Extensible: New notification types require only a new class and a new Enum value

How It Works

Interface (Notification): Defines the sendNotification() contract all channels must follow
Concrete Classes: Each class implements its own channel-specific delivery logic
Factory (NotificationFactory): Takes a NotificationType Enum and returns the right object
Client (main): Only talks to the factory and the interface — never touches concrete classes directly

Sample Output

LLD-9:Secure Data Stream System

NOOB — Thu, 25 Jun 2026 14:43:44 +0000

Secure Data Stream System - Decorator Pattern Implementation

This is an implementation of the Decorator design pattern for a secure file-writing module where data must be compressed and encrypted before being saved to disk.

Problem Statement

Building a secure file-writing module where data goes through a processing pipeline before hitting the disk. The order of operations matters — data must be encrypted first, then compressed (or vice versa), and the system must be flexible enough to add or remove processing steps without rewriting core logic.

Key Challenge: The data pipeline requires:

Encryption: Reverse the string ("SystemDesign" → "ngiseDmetsyS")
Compression: Add a tag ("ngiseDmetsyS" → "(Compressed) ngiseDmetsyS")
Steps must be stackable in any order

Class Diagram

          +----------------+
          |   DataSource   | <-------------------------+
          |   (Interface)  |                           |
          +----------------+                           |
          | + writeData()  |                           |
          +-------+--------+                           |
                  ^                                    |
                  | (Implements)                       |
                  |                                    | (Wraps / Has-A)
       +----------+-----------+             +----------+----------+
       |                      |             |                     |
 +-----+----------+    +------+-------------+---+      +----------+----------+
 | FileDataSource |    |  DataSourceDecorator   |<>----|    wrappee field    |
 +----------------+    |       (Abstract)       |      +---------------------+
 | prints to file |    +------------------------+
 +----------------+              ^
                                 | (Extends)
                                 |
                  +--------------+--------------+
                  |                             |
         +--------+----------+         +--------+-----------+
         |EncryptionDecorator|         |CompressionDecorator|
         +-------------------+         +--------------------+
         | + writeData(data) |         | + writeData(data)  |
         |   reverse string  |         |   add prefix       |
         |   super.write(..) |         |   super.write(..)  |
         +-------------------+         +--------------------+

Implementation

package decorator.secureDataStreamSystem;

public class SecureDataStreamSystem {

    // ==========================================
    // 1. The Component Interface
    // ==========================================
    interface DataSource {
        void writeData(String data);
    }

    // ==========================================
    // 2. The Concrete Component (The Base)
    // ==========================================
    static class FileDataSource implements DataSource {
        @Override
        public void writeData(String data) {
            System.out.println("Writing to file: " + data);
        }
    }

    // ==========================================
    // 3. The Abstract Decorator
    // ==========================================
    static abstract class DataSourceDecorator implements DataSource {
        protected DataSource wrappee; // The next layer in the chain

        public DataSourceDecorator(DataSource wrappee) {
            this.wrappee = wrappee;
        }

        @Override
        public void writeData(String data) {
            wrappee.writeData(data); // Pass it down
        }
    }

    // ==========================================
    // 4. Concrete Decorator (Encryption)
    // ==========================================
    static class EncryptionDecorator extends DataSourceDecorator {
        public EncryptionDecorator(DataSource wrappee) {
            super(wrappee);
        }

        @Override
        public void writeData(String data) {
            // 1. Intercept and Modify the Data (Reverse it)
            String encryptedData = new StringBuilder(data).reverse().toString();

            System.out.println("[Encryption] Reversing data...");

            // 2. Pass the MODIFIED data down the chain
            super.writeData(encryptedData);
        }
    }

    // ==========================================
    // 5. Concrete Decorator (Compression)
    // ==========================================
    static class CompressionDecorator extends DataSourceDecorator {
        public CompressionDecorator(DataSource wrappee) {
            super(wrappee);
        }

        @Override
        public void writeData(String data) {
            // 1. Intercept and Modify the Data (Add prefix)
            String compressedData = "(Compressed) " + data;

            System.out.println("[Compression] Adding compression tag...");

            // 2. Pass the MODIFIED data down the chain
            super.writeData(compressedData);
        }
    }

    // ==========================================
    // 6. Main Driver
    // ==========================================
    public static void main(String[] args) {
        System.out.println("---- Secure File Write Simulation ----\n");

        // We wrap from the inside out: File <- Compression <- Encryption
        DataSource secureFile = new EncryptionDecorator(
                new CompressionDecorator(
                        new FileDataSource()
                )
        );

        // The client only needs to pass the plain text.
        // The decorators handle the rest!
        secureFile.writeData("SystemDesign");
    }
}

Key Features

Decorator Pattern: Dynamically adds processing steps without modifying the base class
Pipeline Processing: Data flows through a chain of transformations in a defined order
Order Matters: Wrapping order determines the processing sequence
Single Responsibility: Each decorator handles exactly one transformation
Transparent to Client: Client simply calls writeData() with plain text
Extensible: New processing steps (e.g., hashing, encoding) can be added without modifying existing code

How It Works

Component Interface (DataSource): Defines the common writeData() contract
Concrete Component (FileDataSource): The base — simply writes data to file
Abstract Decorator (DataSourceDecorator): Holds a reference to the next layer and delegates calls
Concrete Decorators: Intercept data, transform it, then pass it down the chain
Wrapping Order: EncryptionDecorator → CompressionDecorator → FileDataSource

Sample Output

LLD-8:Pizza Topping System

NOOB — Mon, 16 Feb 2026 05:18:05 +0000

Pizza Topping System - Decorator Pattern Implementation

This is an implementation of the Decorator design pattern for a pizza shop billing system demonstrating how to stack multiple decorators of the same type for customizable orders.

Problem Statement

Building a billing system for a Pizza shop where customers can add multiple toppings, including multiple instances of the same topping. The challenge is handling orders like "Double Cheese Paneer Margherita" where the same decorator (Cheese) is applied twice.

Scenario:

You are building the billing system for a Pizza shop.
Base Pizza: Margherita costs ₹100.Toppings
(Decorators):ExtraCheese: Costs ₹20.Paneer:
Costs ₹60.
The Challenge:
A customer wants a "Double Cheese Paneer Margherita".
This means: Margherita + ExtraCheese + ExtraCheese + Paneer.
Total Cost: $100 + 20 + 20 + 60 = 200.

Key Challenge: A customer wants:

Margherita + ExtraCheese + ExtraCheese + Paneer
Total Cost: ₹100 + ₹20 + ₹20 + ₹60 = ₹200
Must support stacking the same decorator multiple times

Class Diagram

          +----------------+
          |     Pizza      | <-------------------------+
          |   (Interface)  |                           |
          +----------------+                           |
          | + getCost()    |                           |
          | + getDesc()    |                           |
          +-------+--------+                           |
                  ^                                    |
                  | (Implements)                       |
                  |                                    | (Wraps / Has-A)
       +----------+-----------+             +----------+----------+
       |                      |             |                     |
 +-----+-----------+    +-----+-------------+---+      +----------+----------+
 | MargheritaPizza |    |     PizzaDecorator    |<>----|     pizza field     |
 +-----------------+    |       (Abstract)      |      +---------------------+
 | Returns 100.0   |    +-----------------------+
 +-----------------+              ^
                                  | (Extends)
                                  |
                   +--------------+--------------+
                   |                             |
          +--------+--------+           +--------+--------+
          | CheeseDecorator |           | PaneerDecorator |
          +-----------------+           +-----------------+
          | + getCost()     |           | + getCost()     |
          |   return 20.0   |           |   return 60.0   |
          |   + super.cost  |           |   + super.cost  |
          +-----------------+           +-----------------+

Implementation

package decorator.pizzatoppingsystem;

/**
 * Pizza Topping System using the Decorator Pattern.
 * Demonstrates recursive composition to calculate total cost.
 */
public class PizzaToppingSystem {

    /**
     * Component Interface.
     * Defines the blueprint for Base Pizzas and Decorators.
     */
    interface Pizza {
        String getDescription();
        double getCost();
    }

    /**
     * Concrete Component (The Base Object).
     */
    static class MargheritaPizza implements Pizza {
        @Override
        public String getDescription() {
            return "Margherita Pizza";
        }

        @Override
        public double getCost() {
            return 100.00;
        }
    }

    /**
     * Abstract Decorator.
     * Contains a reference to a Pizza object (HAS-A relationship).
     */
    static abstract class PizzaDecorator implements Pizza {
        protected Pizza pizza; // The object being wrapped

        public PizzaDecorator(Pizza pizza) {
            this.pizza = pizza;
        }

        @Override
        public String getDescription() {
            return pizza.getDescription(); // Delegate to wrapped object
        }

        @Override
        public double getCost() {
            return pizza.getCost(); // Delegate to wrapped object
        }
    }

    /**
     * Concrete Decorator (Adds Cheese).
     */
    static class CheeseDecorator extends PizzaDecorator {
        public CheeseDecorator(Pizza pizza) {
            super(pizza);
        }

        @Override
        public String getDescription() {
            return super.getDescription() + ", Cheese";
        }

        @Override
        public double getCost() {
            return super.getCost() + 20.00;
        }
    }

    /**
     * Concrete Decorator (Adds Paneer).
     */
    static class PaneerDecorator extends PizzaDecorator {
        public PaneerDecorator(Pizza pizza) {
            super(pizza);
        }

        @Override
        public String getDescription() {
            return super.getDescription() + ", Paneer";
        }

        @Override
        public double getCost() {
            return super.getCost() + 60.00;
        }
    }

    public static void main(String[] args) {
        System.out.println("---- Pizza Shop Order ----");

        // 1. Order Base Pizza
        Pizza margheritaPizza = new MargheritaPizza();
        System.out.println(margheritaPizza.getDescription() + " : Rs. " + 
                         margheritaPizza.getCost());

        // 2. Add Cheese
        margheritaPizza = new CheeseDecorator(margheritaPizza);
        System.out.println(margheritaPizza.getDescription() + " : Rs. " + 
                         margheritaPizza.getCost());

        // 3. Add Extra Cheese (Recursion)
        margheritaPizza = new CheeseDecorator(margheritaPizza);
        System.out.println(margheritaPizza.getDescription() + " : Rs. " + 
                         margheritaPizza.getCost());

        // 4. Add Paneer
        margheritaPizza = new PaneerDecorator(margheritaPizza);
        System.out.println(margheritaPizza.getDescription() + " : Rs. " + 
                         margheritaPizza.getCost());
    }
}

Key Features

Decorator Pattern: Dynamically adds toppings to pizza without modifying base class
Recursive Stacking: Same decorator can be applied multiple times (double cheese, triple cheese, etc.)
Flexible Combinations: Any combination of toppings in any order
Composition over Inheritance: Uses wrapping instead of creating subclasses for each combination
Open/Closed Principle: Open for extension, closed for modification
Cost Accumulation: Each decorator adds its cost to the wrapped object's cost

How It Works

Component Interface (Pizza): Defines common operations for base pizzas and decorators
Concrete Component (MargheritaPizza): The base pizza without any toppings
Abstract Decorator (PizzaDecorator): Holds a reference to a Pizza object and delegates operations
Concrete Decorators (CheeseDecorator, PaneerDecorator): Add specific toppings and costs
Recursive Wrapping: Each decorator wraps the previous object, creating a nested chain

Sample Output

---- Pizza Shop Order ----
Margherita Pizza : Rs. 100.0
Margherita Pizza, Cheese : Rs. 120.0
Margherita Pizza, Cheese, Cheese : Rs. 140.0
Margherita Pizza, Cheese, Cheese, Paneer : Rs. 200.0

Visualization of Recursive Wrapping

Order: Margherita + Cheese + Cheese + Paneer

PaneerDecorator (₹60)
    └── wraps CheeseDecorator (₹20)
            └── wraps CheeseDecorator (₹20)
                    └── wraps MargheritaPizza (₹100)

When getCost() is called:
1. PaneerDecorator.getCost() = super.getCost() + 60.00
2. CheeseDecorator.getCost() = super.getCost() + 20.00
3. CheeseDecorator.getCost() = super.getCost() + 20.00
4. MargheritaPizza.getCost() = 100.00
5. Result: 100.00 + 20.00 + 20.00 + 60.00 = 200.00

Real-World Applications

Pizza ordering systems (Domino's, Pizza Hut)
Burger customization (extra patties, extra cheese)
Sandwich builders (Subway)
Ice cream with multiple scoops and toppings
Car wash packages (basic + wax + tire shine)
Software feature bundles
Cloud service add-ons

Key Advantage: Stacking Same Decorator

Problem Without Decorator:

Need separate classes: PizzaWithCheese, PizzaWithDoubleCheese, PizzaWithTripleCheese
Exponential class explosion with combinations

Solution With Decorator:

Pizza pizza = new MargheritaPizza();
pizza = new CheeseDecorator(pizza);  // Add cheese once
pizza = new CheeseDecorator(pizza);  // Add cheese again
pizza = new CheeseDecorator(pizza);  // Add cheese third time
// Can stack indefinitely!

Adding New Toppings

Adding a new topping is straightforward:

static class OlivesDecorator extends PizzaDecorator {
    public OlivesDecorator(Pizza pizza) {
        super(pizza);
    }

    @Override
    public String getDescription() {
        return super.getDescription() + ", Olives";
    }

    @Override
    public double getCost() {
        return super.getCost() + 15.00;
    }
}

No need to modify existing code - just add the new decorator class!

Extension Ideas

// Create complex orders easily
Pizza vegSupreme = new MargheritaPizza();
vegSupreme = new CheeseDecorator(vegSupreme);
vegSupreme = new PaneerDecorator(vegSupreme);
vegSupreme = new OlivesDecorator(vegSupreme);
vegSupreme = new MushroomDecorator(vegSupreme);
vegSupreme = new CheeseDecorator(vegSupreme);  // Extra cheese on top!

System.out.println(vegSupreme.getDescription() + " : Rs. " + vegSupreme.getCost());
// Output: Margherita Pizza, Cheese, Paneer, Olives, Mushroom, Cheese : Rs. 235.0

LLD-7:Coffee Shop System

NOOB — Mon, 16 Feb 2026 04:29:28 +0000

Coffee Shop System - Decorator Pattern Implementation

This is an implementation of the Decorator design pattern for a coffee shop billing system where customers can dynamically add various toppings to their base coffee order.

Problem Statement

Building billing software for a coffee shop (like Starbucks) where customers can customize their coffee with various add-ons. The challenge is to handle dynamic combinations of add-ons without creating separate classes for every possible combination (Coffee, CoffeeWithMilk, CoffeeWithSugar, CoffeeWithMilkAndSugar, etc.).

Base Item: A SimpleCoffee costs $5.0.

Add-ons (Decorators):
Milk: Costs +$2.0.
Sugar: Costs +$1.0.
The Challenge:
A customer can order:
Just Coffee.
Coffee + Milk.
Coffee + Milk + Sugar.
Coffee + Milk + Milk (Double Milk!).
Requirements:
Interface: Coffee with methods:
double getCost()
String getDescription()

Key Challenge: A customer can order:

Just Coffee
Coffee + Milk
Coffee + Milk + Sugar
Coffee + Milk + Milk (Double Milk!)
Any combination of add-ons in any order

Class Diagram

          +----------------+
          |     Coffee     | <-------------------------+
          |   (Interface)  |                           |
          +----------------+                           |
          | + getCost()    |                           |
          | + getDesc()    |                           |
          +-------+--------+                           |
                  ^                                    |
                  | (Implements)                       |
                  |                                    | (Wraps / Has-A)
       +----------+-----------+             +----------+----------+
       |                      |             |                     |
 +-----+--------+    +--------+-------------+---+      +----------+----------+
 | SimpleCoffee |    |      CoffeeDecorator     |<>----|   coffee field      |
 +--------------+    |         (Abstract)       |      +---------------------+
 | Returns 10.0 |    +--------------------------+
 +--------------+                 ^
                                  | (Extends)
                                  |
                   +--------------+--------------+
                   |                             |
          +--------+--------+           +--------+--------+
          |  MilkDecorator  |           |  SugarDecorator |
          +-----------------+           +-----------------+
          | + getCost()     |           | + getCost()     |
          |   return 2.0    |           |   return 5.0    |
          |   + super.cost  |           |   + super.cost  |
          +-----------------+           +-----------------+

Implementation

package decorator.coffeeshopsystem;

public class CoffeeShopSystem {

    /**
     * Component Interface.
     * Defines the blueprint for both the base object and the decorators.
     */
    interface Coffee {
        String getDescription();
        double getCost();
    }

    /**
     * Concrete Component.
     * The base object (plain coffee) that we will decorate.
     */
    static class SimpleCoffee implements Coffee {
        @Override
        public String getDescription() {
            return "Simple Coffee";
        }

        @Override
        public double getCost() {
            return 10.0;
        }
    }

    /**
     * Abstract Decorator.
     * Implements the interface AND holds a reference to a Component (HAS-A relationship).
     */
    static abstract class CoffeeDecorator implements Coffee {
        protected Coffee coffee; // The object being wrapped

        public CoffeeDecorator(Coffee coffee) {
            this.coffee = coffee;
        }

        @Override
        public String getDescription() {
            return coffee.getDescription(); // Delegate to the wrapped object
        }

        @Override
        public double getCost() {
            return coffee.getCost(); // Delegate to the wrapped object
        }
    }

    /**
     * Concrete Decorator (Milk).
     * Adds functionality (cost and description) to the wrapped object.
     */
    static class MilkDecorator extends CoffeeDecorator {
        public MilkDecorator(Coffee coffee) {
            super(coffee);
        }

        @Override
        public String getDescription() {
            return super.getDescription() + ", Milk";
        }

        @Override
        public double getCost() {
            return super.getCost() + 2.0; // Add cost of Milk
        }
    }

    /**
     * Concrete Decorator (Sugar).
     * Adds functionality (cost and description) to the wrapped object.
     */
    static class SugarDecorator extends CoffeeDecorator {
        public SugarDecorator(Coffee coffee) {
            super(coffee);
        }

        @Override
        public String getDescription() {
            return super.getDescription() + ", Sugar";
        }

        @Override
        public double getCost() {
            return super.getCost() + 5.0; // Add cost of Sugar
        }
    }

    public static void main(String[] args) {
        System.out.println("---- Coffee Shop Order ----");

        // 1. Order Base Coffee
        Coffee myCoffee = new SimpleCoffee();
        System.out.println(myCoffee.getDescription() + " : $" + myCoffee.getCost());

        // 2. Decorate with Milk
        myCoffee = new MilkDecorator(myCoffee);
        System.out.println(myCoffee.getDescription() + " : $" + myCoffee.getCost());

        // 3. Decorate with Sugar
        myCoffee = new SugarDecorator(myCoffee);
        System.out.println(myCoffee.getDescription() + " : $" + myCoffee.getCost());
    }
}

Key Features

Decorator Pattern: Dynamically adds responsibilities to objects without modifying their classes
Flexible Combinations: Supports any combination of add-ons in any order
Open/Closed Principle: Open for extension (new decorators), closed for modification
Single Responsibility: Each decorator has one specific responsibility
Composition over Inheritance: Uses wrapping instead of subclassing
Stackable Decorators: Can apply multiple decorators to the same object

How It Works

Component Interface (Coffee): Defines the common interface for both base objects and decorators
Concrete Component (SimpleCoffee): The basic coffee without any add-ons
Abstract Decorator (CoffeeDecorator): Implements the Coffee interface and holds a reference to a Coffee object
Concrete Decorators (MilkDecorator, SugarDecorator): Add specific functionality by wrapping the coffee object
Wrapping Process: Each decorator wraps the previous object, creating a chain of decorators

Sample Output

---- Coffee Shop Order ----
Simple Coffee : $10.0
Simple Coffee, Milk : $12.0
Simple Coffee, Milk, Sugar : $17.0

Visualization of Wrapping

Order: Coffee + Milk + Sugar

SugarDecorator
    └── wraps MilkDecorator
            └── wraps SimpleCoffee

When getCost() is called:
1. SugarDecorator.getCost() = super.getCost() + 5.0
2. MilkDecorator.getCost() = super.getCost() + 2.0
3. SimpleCoffee.getCost() = 10.0
4. Result: 10.0 + 2.0 + 5.0 = 17.0

Real-World Applications

Coffee shop ordering systems (Starbucks, Dunkin')
Pizza topping customization
Car configuration with optional features
Insurance policy add-ons
Software licensing with feature modules
Stream/IO operations in Java (BufferedReader wrapping FileReader)
UI component decoration (borders, scrollbars)

Advantages Over Inheritance

Without Decorator (Using Inheritance):

CoffeeWithMilk
CoffeeWithSugar
CoffeeWithMilkAndSugar
CoffeeWithDoubleMilk
CoffeeWithDoubleMilkAndSugar
... (Class explosion!)

With Decorator:

SimpleCoffee
MilkDecorator
SugarDecorator
Can create any combination dynamically!

Adding New Decorators

Adding a new add-on is simple:

static class WhippedCreamDecorator extends CoffeeDecorator {
    public WhippedCreamDecorator(Coffee coffee) {
        super(coffee);
    }

    @Override
    public String getDescription() {
        return super.getDescription() + ", Whipped Cream";
    }

    @Override
    public double getCost() {
        return super.getCost() + 3.0;
    }
}

No need to modify existing code - just add the new decorator class!

LLD-6:YouTube Subscription System

NOOB — Sat, 14 Feb 2026 23:28:02 +0000

YouTube Subscription System - Observer Pattern Implementation

This is an implementation of the Observer design pattern for a YouTube-style subscription system demonstrating many-to-many relationships where multiple users can subscribe to multiple channels.

Problem Statement

Designing the notification backend for YouTube where multiple channels (Subjects) can have multiple subscribers (Observers), and each channel maintains its own independent subscriber list. When a channel uploads a video, only its subscribers should be notified - not subscribers of other channels.

The Challenge:

Shiv subscribes to MrBeast.
Aeris subscribes to MrBeast AND GeeksForGeeks.
Bob subscribes to T-Series.
Action: When MrBeast uploads a video, only Shiv and Aeris should get notified. Bob should NOT get notified.
Requirements:
Observer Interface: void notify(String channelName, String videoTitle).
Subject Interface: subscribe(Observer), unsubscribe(Observer), uploadVideo(String title).
Concrete Subject (YoutubeChannel):
Has a channelName.
Has its own list of subscribers (this is the key!).
Concrete Observer (YoutubeUser):
Has a userName.
Prints: "[Notification] Hello , just uploaded: "

Key Challenge: Managing independent notification lists for multiple subjects where:

Shiv subscribes to MrBeast
Tina subscribes to MrBeast AND GFG
Laxmi subscribes to T-Series
When MrBeast uploads, only Shiv and Tina get notified (not Laxmi)

Class Diagram

        +------------------+             +-----------------------+
        |     Subject      |             |       Observer        |
        |   (Interface)    |             |      (Interface)      |
        +------------------+             +-----------------------+
        | + subscribe()    |             | + update()            |
        | + unsubscribe()  |             +-----------+-----------+
        | + notify()       |                         ^
        +--------+---------+                         |
                 ^                                   | (Implements)
                 | (Implements)                      |
                 |                                   |
        +--------+---------+             +-----------+-----------+
        |  YoutubeChannel  |<>---------->|      YouTubeUser      |
        +------------------+   (List)    +-----------------------+
        | - channelName    |             | - userName            |
        | - subscribers [] |             | + update(msg)         |
        | + uploadVideo()  |             +-----------------------+
        +------------------+

Implementation

package observer.youtubesubscriptionsystem;

import java.util.ArrayList;
import java.util.List;

/**
 * YouTube Subscription System demonstrating Many-to-Many Observer Pattern.
 */
public class YoutubeSubscriptionSystem {

    /**
     * Observer interface for Users.
     */
    interface Observer {
        void update(String channelName, String videoTitle);
    }

    /**
     * Subject interface for Channels.
     */
    interface Subject {
        void subscribe(Observer observer);
        void unsubscribe(Observer observer);
        void notifySubscribers(String videoTitle);
    }

    /**
     * Concrete Subject representing a specific YouTube Channel.
     */
    static class YoutubeChannel implements Subject {
        private final String channelName;
        private final List<Observer> subscribers = new ArrayList<>();

        public YoutubeChannel(String channelName) {
            this.channelName = channelName;
        }

        @Override
        public void subscribe(Observer observer) {
            subscribers.add(observer);
            System.out.println("[System] New Subscriber added to " + this.channelName);
        }

        @Override
        public void unsubscribe(Observer observer) {
            subscribers.remove(observer);
            System.out.println("[System] Subscriber removed from " + this.channelName);
        }

        @Override
        public void notifySubscribers(String videoTitle) {
            for (Observer observer : subscribers) {
                observer.update(this.channelName, videoTitle);
            }
        }

        /**
         * Simulates a video upload and notifies subscribers.
         */
        public void uploadVideo(String videoTitle) {
            System.out.println("\n------------------------------------");
            System.out.println("Uploading to [" + this.channelName + "]: " + 
                             videoTitle);
            System.out.println("------------------------------------");
            notifySubscribers(videoTitle);
        }
    }

    /**
     * Concrete Observer representing a User.
     */
    static class YouTubeUser implements Observer {
        private final String userName;

        public YouTubeUser(String userName) {
            this.userName = userName;
        }

        @Override
        public void update(String channelName, String videoTitle) {
            System.out.println(" => [Notification] Hey " + userName + ", " + 
                             channelName + " just uploaded: \"" + videoTitle + "\"");
        }
    }

    public static void main(String[] args) {
        YoutubeChannel mrBeast = new YoutubeChannel("MrBeast");
        YoutubeChannel gfg = new YoutubeChannel("GFG");
        YoutubeChannel tseries = new YoutubeChannel("T-Series");

        Observer shiv = new YouTubeUser("Shiv");
        Observer tina = new YouTubeUser("Tina");
        Observer laxmi = new YouTubeUser("Laxmi");

        System.out.println("----Setting up Subscriptions----");

        // Shiv follows MrBeast
        mrBeast.subscribe(shiv);

        // Tina follows MrBeast AND GFG
        mrBeast.subscribe(tina);
        gfg.subscribe(tina);

        // Laxmi follows T-Series
        tseries.subscribe(laxmi);

        // --- SCENARIO 1: Uploads ---
        mrBeast.uploadVideo("I Built a Chocolate Factory!");
        gfg.uploadVideo("Observer pattern in 5 mins");
        tseries.uploadVideo("New Punjabi Song");

        // --- SCENARIO 2: Unsubscribe ---
        System.out.println("\n----Laxmi Unsubscribes from T-Series----");
        tseries.unsubscribe(laxmi);

        tseries.uploadVideo("Another Hit Song");
    }
}

Key Features

Many-to-Many Relationship: Users can subscribe to multiple channels, channels can have multiple subscribers
Independent Subscriber Lists: Each channel maintains its own list of subscribers
Targeted Notifications: Only relevant subscribers receive notifications
Dynamic Subscriptions: Users can subscribe and unsubscribe at runtime
Personalized Notifications: Each notification includes both channel name and video title
Extensible: Easy to add new channels and users without modifying existing code

How It Works

Multiple Subjects: Each YouTube channel is an independent subject with its own subscriber list
Multiple Observers: Users can subscribe to any number of channels
Subscription: Users call channel.subscribe(user) to start receiving notifications
Upload & Notify: When a channel uploads via uploadVideo(), only its subscribers are notified
Unsubscription: Users can call channel.unsubscribe(user) to stop receiving notifications

Sample Output

----Setting up Subscriptions----
[System] New Subscriber added to MrBeast
[System] New Subscriber added to MrBeast
[System] New Subscriber added to GFG
[System] New Subscriber added to T-Series

------------------------------------
Uploading to [MrBeast]: I Built a Chocolate Factory!
------------------------------------
 => [Notification] Hey Shiv, MrBeast just uploaded: "I Built a Chocolate Factory!"
 => [Notification] Hey Tina, MrBeast just uploaded: "I Built a Chocolate Factory!"

------------------------------------
Uploading to [GFG]: Observer pattern in 5 mins
------------------------------------
 => [Notification] Hey Tina, GFG just uploaded: "Observer pattern in 5 mins"

------------------------------------
Uploading to [T-Series]: New Punjabi Song
------------------------------------
 => [Notification] Hey Laxmi, T-Series just uploaded: "New Punjabi Song"

----Laxmi Unsubscribes from T-Series----
[System] Subscriber removed from T-Series

------------------------------------
Uploading to [T-Series]: Another Hit Song
------------------------------------

Notice how after Laxmi unsubscribes, the last T-Series upload doesn't generate any notification!

Real-World Applications

YouTube subscription and notification system
Social media follow/follower systems (Twitter, Instagram)
Newsletter subscription platforms
Podcast notification systems
Blog RSS feed subscriptions
Event notification systems
Push notification services

Key Differences from Previous Examples

Unlike the Weather Station or Stock Market examples where there was typically one subject broadcasting to multiple observers, this system demonstrates:

Multiple independent subjects (channels)
Many-to-many relationships (users subscribe to multiple channels)
Isolated notification lists (each channel has its own subscribers)
Cross-subscription (same user can observe multiple subjects)

LLD-5.5:Traffic Signal System

NOOB — Sat, 14 Feb 2026 21:23:38 +0000

Traffic Signal System - Observer Pattern Implementation

This is an implementation of the Observer design pattern for a Smart City traffic intersection where vehicles and pedestrians react differently to the same signal changes.

Problem Statement

Designing software for a Smart City intersection where a traffic signal changes colors (RED, GREEN) and different types of observers must react appropriately. The unique challenge here is that unlike typical observer patterns where all observers handle updates similarly, vehicles and pedestrians have opposite behaviors for the same signal state.

The Challenge:

Unlike the Stock/Weather examples where everyone just "printed" the new value,
here the Logic is opposite for the two observers.
If Signal is GREEN: Cars GO, Pedestrians STOP.
If Signal is RED: Cars STOP, Pedestrians GO.
Requirements:
Enum: Create a SignalColor enum (RED, GREEN, ORANGE).
Observer Interface: void update(SignalColor color).
Subject: TrafficLight class.
Methods: addObserver, removeObserver, changeSignal(SignalColor color).
Logic:
Create a Car observer.
Create a Pedestrian observer.
Change the signal to GREEN and watch them react differently.

Key Challenge:

When signal is GREEN → Cars GO, Pedestrians WAIT
When signal is RED → Cars STOP, Pedestrians WALK

Class Diagram

        +------------------+             +-----------------------+
        |     Subject      |             |       Observer        |
        |   (Interface)    |             |      (Interface)      |
        +------------------+             +-----------------------+
        | + add(obs)       |             | + update(color)       |
        | + remove(obs)    |             +-----------+-----------+
        | + notify()       |                         ^
        +--------+---------+                         |
                 ^                                   | (Implements)
                 | (Implements)                      |
                 |                                   |
        +--------+---------+             +-----------+-----------+----------------+
        |  SignalStation   |<>---------->|                       |                |
        +------------------+   (List)    |  +----------------+   |  +----------+  |
        | - observers List |             |  | VehicleObserver|   |  |WalkObserver| |
        | - signalColor    |             |  +----------------+   |  +----------+  |
        | + updateSignal() |             |  | - name         |   |  | -name      | |
        +------------------+             |  | + update()     |   |  | +update()  | |
                                         |  +----------------+   |  +----------+  |
                                         +-----------------------+----------------+

Implementation

package observer.trafficsignalsystem;

import java.util.ArrayList;
import java.util.List;

/**
 * Main system demonstrating the Observer Pattern for traffic control.
 * Vehicles and Pedestrians react differently to the same signal change.
 */
public class TrafficSignalSystem {

    /**
     * Enum defining the possible states of a traffic signal.
     */
    enum SignalColor {
        GREEN,
        RED
    }

    /**
     * Observer interface for any entity reacting to traffic lights.
     */
    interface Observer {
        /**
         * Triggered when the signal color changes.
         */
        void update(SignalColor signalColor);
    }

    /**
     * Subject interface for managing subscriptions.
     */
    interface Subject {
        void addObserver(Observer observer);
        void removeObserver(Observer observer);
        void notifyObservers();
    }

    /**
     * Concrete Subject acting as the Traffic Signal Station.
     */
    static class SignalStation implements Subject {
        private final List<Observer> observers = new ArrayList<>();
        private SignalColor signalColor;

        @Override
        public void addObserver(Observer observer) {
            observers.add(observer);
        }

        @Override
        public void removeObserver(Observer observer) {
            observers.remove(observer);
        }

        @Override
        public void notifyObservers() {
            for (Observer observer : observers) {
                observer.update(signalColor);
            }
        }

        /**
         * Updates the signal color and triggers notification.
         */
        public void updateTrafficSignal(SignalColor signalColor) {
            this.signalColor = signalColor;
            System.out.println("\n[SignalStation] Signal changed to: " + signalColor);
            notifyObservers();
        }
    }

    /**
     * Concrete Observer representing a Vehicle.
     * Stops on RED, Moves on GREEN.
     */
    static class VehicleObserver implements Observer {
        private final String name;

        public VehicleObserver(String name) {
            this.name = name;
        }

        @Override
        public void update(SignalColor signalColor) {
            if (signalColor == SignalColor.GREEN) {
                System.out.println("  [Car] " + name + ": Green Light! Vroom Vroom...");
            } else {
                System.out.println("  [Car] " + name + ": Red Light! Screech... Stop.");
            }
        }
    }

    /**
     * Concrete Observer representing a Pedestrian.
     * Stops on GREEN, Moves on RED.
     */
    static class WalkObserver implements Observer {
        private final String name;

        public WalkObserver(String name) {
            this.name = name;
        }

        @Override
        public void update(SignalColor signalColor) {
            if (signalColor == SignalColor.GREEN) {
                System.out.println("  [Walker] " + name + 
                                 ": Green Light! Wait for cars.");
            } else {
                System.out.println("  [Walker] " + name + 
                                 ": Red Light! Safe to cross.");
            }
        }
    }

    /**
     * Main driver method to simulate the traffic signal logic.
     */
    public static void main(String[] args) {
        SignalStation suratTrafficStation = new SignalStation();

        System.out.println("\n----Simulation Started----\n");

        Observer walker1 = new WalkObserver("Shiv");
        Observer car1 = new VehicleObserver("BMW");

        suratTrafficStation.addObserver(walker1);
        suratTrafficStation.addObserver(car1);

        System.out.println("\n------- Signal -> GREEN -------");
        suratTrafficStation.updateTrafficSignal(SignalColor.GREEN);

        System.out.println("\n------- Signal -> RED -------");
        suratTrafficStation.updateTrafficSignal(SignalColor.RED);
    }
}

Key Features

Observer Pattern: Implements one-to-many dependency for traffic signal updates
Opposite Behaviors: Different observers react differently to the same event
Type Safety: Uses Enum for signal colors instead of strings
Extensible: Easy to add new observer types (Bicycles, Emergency Vehicles, etc.)
Real-time Coordination: All observers receive updates simultaneously
Loose Coupling: SignalStation doesn't need to know about specific observer implementations

How It Works

Subject (SignalStation): Maintains the current signal color and list of observers
Observers (VehicleObserver, WalkObserver): Implement different logic for the same signal state
Registration: Vehicles and pedestrians register using addObserver()
State Change: When signal changes via updateTrafficSignal(), all observers are notified
Custom Logic: Each observer type implements its own behavior based on the signal color

Sample Output

----Simulation Started----


------- Signal -> GREEN -------

[SignalStation] Signal changed to: GREEN
  [Walker] Shiv: Green Light! Wait for cars.
  [Car] BMW: Green Light! Vroom Vroom...

------- Signal -> RED -------

[SignalStation] Signal changed to: RED
  [Walker] Shiv: Red Light! Safe to cross.
  [Car] BMW: Red Light! Screech... Stop.

Real-World Applications

Smart City traffic management systems
Autonomous vehicle coordination
Pedestrian crossing safety systems
Emergency vehicle priority signaling
Traffic flow optimization
Intersection collision avoidance

Extensions

This pattern can be extended to support:

ORANGE/YELLOW signals for warning states
Emergency vehicles that override normal behavior
Bicycles with different rules than cars
Traffic statistics observers that log traffic patterns
Adaptive signals that adjust timing based on traffic density

LLD-5:Stock Market Notification System

NOOB — Sat, 14 Feb 2026 17:35:35 +0000

Stock Market Notification System - Observer Pattern Implementation

This is an implementation of the Observer design pattern for a trading application where investors receive real-time stock price updates through different notification channels.

Problem Statement

Building a backend for a trading app like Zerodha or Robinhood where multiple investors need to be notified when stock prices change. Unlike simple notifications, stock updates need to convey both the stock name and the current price. Different investors may prefer different notification channels (email, mobile app, SMS, etc.).

The Challenge:

Unlike the Weather Station (which just sent one number), a Stock update needs to convey two things:
Which Stock? (Name)
What Price? (Amount)
The system must allow an investor (e.g., "Shiv") to subscribe to updates.
Requirements:
Observer Interface: The update method should take two arguments: String stockName and double price.
Subject Interface: Standard addObserver, removeObserver, notifyObservers.
Concrete Subject (Stock)
:Has fields: stockName, price, list of observers.
Method setPrice(newPrice) $\rightarrow$ Updates price and notifies everyone.
Concrete Observers:
MobileAlertObserver: Prints "Notification sent to mobile: [Name] - [Stock] is now [Price]".
EmailAlertObserver: Prints "Email sent to: [Name] - [Stock] is now [Price]".

Key Challenge: The system must support personalized notifications for multiple users across different communication channels, while maintaining loose coupling between the stock ticker and the notification mechanisms.

Class Diagram

        +------------------+             +-----------------------+
        |     Subject      |             |       Observer        |
        |   (Interface)    |             |      (Interface)      |
        +------------------+             +-----------------------+
        | + add(obs)       |             | + update(name, price) |
        | + remove(obs)    |             +-----------+-----------+
        | + notify()       |                         ^
        +--------+---------+                         |
                 ^                                   | (Implements)
                 | (Implements)                      |
                 |                                   |
        +--------+---------+             +-----------+-----------+----------------+
        |   StockTicker    |<>---------->|                       |                |
        +------------------+   (List)    |  +----------------+   |  +----------+  |
        | - observers List |             |  | EmailObserver  |   |  |AppObserver| |
        | - stockName      |             |  +----------------+   |  +----------+  |
        | - stockPrice     |             |  | - username     |   |  | -username|  |
        | + setStockPrice()|             |  | + update()     |   |  | +update()|  |
        +------------------+             |  +----------------+   |  +----------+  |
                                         +-----------------------+----------------+

Implementation

package observer.stockmarketnotificationsystem;

import java.util.ArrayList;
import java.util.List;

/**
 * Main class for the Stock Market Notification System.
 * Demonstrates the Observer Pattern with distinct User Identities.
 */
public class StockMarketNotificationSystem {

    /**
     * Observer Interface.
     * Represents the "Investor" who wants to be notified.
     */
    interface Observer {
        void update(String stockName, double stockPrice);
    }

    /**
     * Subject Interface.
     * Represents the "Stock Market" or "Ticker" that broadcasts updates.
     */
    interface Subject {
        void addObserver(Observer observer);
        void removeObserver(Observer observer);
        void notifyObservers();
    }

    /**
     * Concrete Subject.
     * This acts as the central ticker. When a stock updates, it alerts everyone.
     */
    static class StockTicker implements Subject {
        // List to hold all subscribed investors
        private final List<Observer> observers = new ArrayList<>();

        private String stockName;
        private double stockPrice;

        @Override
        public void addObserver(Observer observer) {
            observers.add(observer);
        }

        @Override
        public void removeObserver(Observer observer) {
            observers.remove(observer);
        }

        @Override
        public void notifyObservers() {
            for (Observer observer : observers) {
                // Pass the state to the observers
                observer.update(stockName, stockPrice);
            }
        }

        public void setStockPrice(String stockName, double stockPrice) {
            this.stockName = stockName;
            this.stockPrice = stockPrice;
            System.out.println("\n[Ticker] New Update: " + stockName + 
                             " is now $" + stockPrice);
            notifyObservers();
        }
    }

    /**
     * Concrete Observer for Email Alerts.
     * Contains the User's Name to make it personalized.
     */
    static class EmailObserver implements Observer {
        private final String username;

        public EmailObserver(String username) {
            this.username = username;
        }

        @Override
        public void update(String stockName, double stockPrice) {
            System.out.println("  -> Email sent to " + username + ": " + 
                             stockName + " is at $" + stockPrice);
        }
    }

    /**
     * Concrete Observer for Mobile App Alerts.
     */
    static class AppObserver implements Observer {
        private final String username;

        public AppObserver(String username) {
            this.username = username;
        }

        @Override
        public void update(String stockName, double stockPrice) {
            System.out.println("  -> App Notification for " + username + ": " + 
                             stockName + " is at $" + stockPrice);
        }
    }

    /**
     * Main Driver Method.
     */
    public static void main(String[] args) {
        StockTicker zerodha = new StockTicker();

        System.out.println("\n--- Simulation Started ---");

        // 1. Create Observers with Names (Identity)
        Observer shiv = new AppObserver("Shiv");
        Observer tina = new AppObserver("Tina");
        Observer laxmi = new EmailObserver("Laxmi");

        // 2. Subscribe them
        zerodha.addObserver(shiv);
        zerodha.addObserver(tina);
        zerodha.addObserver(laxmi);

        // 3. Update Price - Everyone gets notified
        zerodha.setStockPrice("Apple", 238.92);

        // 4. Unsubscribe Logic
        System.out.println("\n--- Shiv unsubscribes ---");
        zerodha.removeObserver(shiv);

        // 5. Update Price again - Shiv should NOT receive this
        zerodha.setStockPrice("Tesla", 500.00);
    }
}

Key Features

Observer Pattern: Implements one-to-many dependency for stock price updates
Personalized Notifications: Each observer has a username for personalized messages
Multiple Notification Channels: Supports email, mobile app, and easily extensible to SMS, desktop, etc.
Multi-parameter Updates: Unlike simple observer patterns, this passes both stock name and price
Dynamic Subscription: Investors can subscribe and unsubscribe at runtime
Loose Coupling: StockTicker doesn't need to know about specific notification implementations

How It Works

Subject (StockTicker): Maintains stock state and list of observers
Observers (EmailObserver, AppObserver): Implement the Observer interface with personalized identities
Registration: Investors register using addObserver()
Notification: When stock price changes via setStockPrice(), all registered observers receive updates with both stock name and price
Unsubscription: Investors can unsubscribe using removeObserver()

Sample Output

--- Simulation Started ---

[Ticker] New Update: Apple is now $238.92
  -> App Notification for Shiv: Apple is at $238.92
  -> App Notification for Tina: Apple is at $238.92
  -> Email sent to Laxmi: Apple is at $238.92

--- Shiv unsubscribes ---

[Ticker] New Update: Tesla is now $500.0
  -> App Notification for Tina: Tesla is at $500.0
  -> Email sent to Laxmi: Tesla is at $500.0

Real-World Applications

Stock trading platforms (Zerodha, Robinhood, E*TRADE)
Cryptocurrency price tracking
Real-time sports score updates
News notification systems
Social media feed updates