Design A Vending Machine - Object-Oriented Design

Requirements

Determine the different ways the system will be used. This includes main functions the system needs to perform and who will use it.

Manage inventory
Handle payments: coins, cash, cards
Provide maintenance alerts

Define Core Objects

Based on the requirements and use cases, identify the main objects of the system...

1. VendingMachine

The central controller of the vending system.

Maintains the inventory of items and handles the purchasing process.

Key responsibilities:

Adding items to inventory.

Processing purchase requests (buying items with different payment modes).

Tracking available items.

2. Items

An abstract class representing any item that can be sold by the vending machine (like drinks, snacks, etc.).

Shared fields:

itemName

price

Abstract or concrete methods for getting item info (like getPrice(), getItemName()).

3. Drinks and 4. Snacks

Concrete subclasses of Items.

Provide specific item information (like name and price).

5. Inventory

If you want to separate out the management of the item list, you can have an Inventory class that holds the List.

Alternatively, the VendingMachine can directly manage the list (as in your current code).

6. Payment

An interface representing a generic payment method.

One method: pay(double amount).

Concrete implementations of this interface process payment in different ways.

7. Payment Implementations

CashPayment – handles cash-based payments.

CoinPayment – handles coin-based payments.

CardPayment – handles card-based payments.

8. Enums

ItemName – defines the types of items the machine can sell (Drinks, Snacks, etc.).

PaymentMode – defines the accepted payment methods (Cash, Coins, Card).

Analyze Relationships

Determine how these objects will interact with each other to fulfill the use cases...

VendingMachine & Items
- VendingMachine manages a list of Items.
- It adds and removes items when users buy them.
Items & Subclasses
- Items is an abstract class with common fields and methods.
- Drinks and Snacks extend Items, providing specific item details.
VendingMachine & Payment
- VendingMachine uses the Payment interface to process payments.
- It creates the right Payment implementation (e.g., CashPayment) based on the payment mode.
Payment & Implementations
- Payment defines the contract for processing payments.
- CashPayment, CoinPayment, and CardPayment implement this contract.
Enums (ItemName, PaymentMode)
- ItemName is used to identify item types.
- PaymentMode is used to select the payment type.

Interaction Flow (Buy Item Use Case)

User chooses an item and payment mode.
VendingMachine finds the item in inventory.
It creates the right Payment implementation.
Calls pay on the Payment instance.
Removes the item if payment succeeds.

Establish Hierarchy

Design inheritance trees where applicable to promote code reuse and polymorphism. This step involves identifying common attributes and behaviors that can be abstracted into parent classes...

1. Items Hierarchy

Abstract Parent Class:

Items

Common attributes: itemName, price

Common methods: getPrice(), getItemName()

Concrete Subclasses:

Drinks

Snacks

Additional types as needed (e.g., Candy, Sandwich)

This setup allows the VendingMachine to work with a common Items interface for different item types, leveraging polymorphism.

2. Payment Hierarchy

Interface:

Payment

Method: pay(double amount)

Implementations:

CashPayment

CardPayment

CoinPayment

The VendingMachine uses the Payment interface, enabling it to handle different payment types uniformly.

Design Patterns

Consider using design patterns (e.g., Factory, Singleton, Observer, Strategy) that fit the problem...

Singleton Pattern

The VendingMachine class is a singleton, ensuring only one instance of the vending machine exists.

Factory Pattern

The PaymentFactory class creates payment objects (CashPayment, CardPayment, etc.) based on the selected payment mode.

Strategy Pattern

The Payment interface and its implementations (CashPayment, CardPayment, etc.) represent interchangeable payment strategies.

Observer Pattern

The MaintenanceSystem is an observer that receives low inventory alerts from the VendingMachine.

Define Class Members (write code)

Attributes: For each class, define the attributes (data) it will hold...

Methods: Define the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation.

import java.util.*;
// --- ENUMS ---
enum ItemName {
Snacks, Drinks
}
enum PaymentMode {
Cash, Coins, Card
}
// --- ITEM HIERARCHY ---
abstract class Item {
protected ItemName name;
protected double price;
public ItemName getName() { return name; }
public double getPrice() { return price; }

}
class Snacks extends Item {
public Snacks() {
this.name = ItemName.Snacks;
this.price = 30.0;
}
}
class Drinks extends Item {
public Drinks() {
this.name = ItemName.Drinks;
this.price = 20.0;
}
}
// --- PAYMENT STRATEGY INTERFACE ---
interface Payment {
void pay(double amount);
}
class CashPayment implements Payment {
public void pay(double amount) {
System.out.println("Paid ₹" + amount + " in cash.");
}
}
class CoinPayment implements Payment {
public void pay(double amount) {
System.out.println("Paid ₹" + amount + " with coins.");
}
}
class CardPayment implements Payment {
public void pay(double amount) {
System.out.println("Paid ₹" + amount + " by card.");
}
}
// --- PAYMENT FACTORY ---
class PaymentFactory {
public static Payment getPayment(PaymentMode mode) {
switch (mode) {
case Cash: return new CashPayment();
case Coins: return new CoinPayment();
case Card: return new CardPayment();
default: throw new IllegalArgumentException("Invalid payment mode");
}
}
}
// --- OBSERVER PATTERN FOR MAINTENANCE ---
interface MaintenanceObserver {
void alertLowInventory(ItemName itemName, int count);
}
class MaintenanceSystem implements MaintenanceObserver {
public void alertLowInventory(ItemName itemName, int count) {
System.out.println("ALERT: Low inventory for " + itemName + " (remaining: " + count + ")");
}
}
// --- VENDING MACHINE SINGLETON ---
class VendingMachine {
private static final VendingMachine instance = new VendingMachine();
private Map&lt;ItemName, Queue&lt;Item&gt;&gt; inventory;
private List&lt;MaintenanceObserver&gt; observers;

private static final int LOW_THRESHOLD = 2;

private VendingMachine() {
    inventory = new HashMap&lt;&gt;();
    observers = new ArrayList&lt;&gt;();
    inventory.put(ItemName.Snacks, new LinkedList&lt;&gt;());
    inventory.put(ItemName.Drinks, new LinkedList&lt;&gt;());
}

public static VendingMachine getInstance() {
    return instance;
}

// Observer registration
public void registerObserver(MaintenanceObserver observer) {
    observers.add(observer);
}

// Notify observers
private void notifyLowInventory(ItemName itemName, int count) {
    for (MaintenanceObserver observer : observers) {
        observer.alertLowInventory(itemName, count);
    }
}

// Add item to inventory
public void addItem(Item item) {
    Queue&lt;Item&gt; items = inventory.get(item.getName());
    items.offer(item);
}

// Buy an item
public void buyItem(ItemName itemName, PaymentMode mode) {
    Queue&lt;Item&gt; items = inventory.get(itemName);
    if (items == null || items.isEmpty()) {
        System.out.println(itemName + &quot; is out of stock.&quot;);
        return;
    }

    Item item = items.poll();
    Payment payment = PaymentFactory.getPayment(mode);
    payment.pay(item.getPrice());

    System.out.println(&quot;Dispensed: &quot; + item.getName());

    // Check for low inventory
    if (items.size() &lt;= LOW_THRESHOLD) {
        notifyLowInventory(itemName, items.size());
    }
}

// Show inventory status
public void showInventory() {
    for (Map.Entry&lt;ItemName, Queue&lt;Item&gt;&gt; entry : inventory.entrySet()) {
        System.out.println(entry.getKey() + &quot;: &quot; + entry.getValue().size());
    }
}

}
// --- MAIN CLASS FOR TESTING ---
public class VendingMachineApp {
public static void main(String[] args) {
VendingMachine vm = VendingMachine.getInstance();
    // Register maintenance observer
    MaintenanceSystem maintenance = new MaintenanceSystem();
    vm.registerObserver(maintenance);

    // Add items
    for (int i = 0; i &lt; 3; i++) {
        vm.addItem(new Snacks());
        vm.addItem(new Drinks());
    }

    vm.showInventory();

    // Buy items
    vm.buyItem(ItemName.Snacks, PaymentMode.Cash);
    vm.buyItem(ItemName.Snacks, PaymentMode.Card);
    vm.buyItem(ItemName.Snacks, PaymentMode.Coins);

    // Inventory status after purchases
    vm.showInventory();

    // Trigger low inventory alert
    vm.buyItem(ItemName.Snacks, PaymentMode.Cash);

    // Buy drinks
    vm.buyItem(ItemName.Drinks, PaymentMode.Card);
    vm.showInventory();
}

}

Adhere to SOLID Guidelines

Check and explain whether your design adheres to solid principles (Ask interviewer what SOLID principle is if you can not recall it.)...

1. Single Responsibility Principle (SRP)

Each class has a clear, focused responsibility: VendingMachine manages inventory, Payment handles payments, MaintenanceSystem handles alerts.

2. Open/Closed Principle (OCP)

New payment types or item types can be added without modifying existing classes. They’re open for extension but closed for modification.

3. Liskov Substitution Principle (LSP)

Subclasses (Snacks, Drinks, CashPayment, etc.) can be used wherever their parent (Item, Payment) is expected, maintaining correct behavior.

4. Interface Segregation Principle (ISP)

No large, general interfaces; the Payment interface is minimal and only includes pay(), making it easy to implement for different payment types.

5. Dependency Inversion Principle (DIP)

High-level modules (VendingMachine) depend on abstractions (Payment interface), not on concrete classes.

Consider Scalability and Flexibility

Explain how your design can handle changes in scale and whether it would be easily to extend with new functionalities...

Scalability

Flexible Inventory Management:

The VendingMachine uses a map of queues (Map>), making it easy to handle more items without changing the core logic.

Dynamic Payment Handling:

Payments are handled via the Payment interface and a factory pattern. Adding new payment types (e.g., mobile wallets) requires minimal changes.

Observer Pattern for Maintenance:

Observers can be added or removed dynamically to handle more maintenance concerns as the system grows.

Flexibility

Adding New Item Types:

Just create a new class extending Item (e.g., Candy extends Item). No changes to VendingMachine.

Adding New Payment Types:

Create a new Payment implementation and update the PaymentFactory. No changes to payment logic in VendingMachine.

Multiple Observers:

You can register additional observers for other notifications (e.g., analytics, restocking services) without modifying the vending machine code.

Create/Explain your diagram(s)

Try creating a class, flow, state and/or sequence diagram using the diagramming tool. Mermaid flow diagrams can be used to represent system use cases. You can ask the interviewer bot to create a starter diagram if unfamiliar with the tool. Briefly explain your diagrams if necessary...

Future improvements

Critically examine your design for any flaws or areas for future improvement...

Hardcoded low threshold: Should be configurable for flexibility.

Basic inventory tracking: Needs better data structures if tracking expiry or lot data.

No thread-safety: Concurrent access could cause issues.

Simplistic payment handling: Lacks validation and real error handling.

No state management: Doesn’t model operational states of the vending machine.

No persistence: Data is lost when the program stops.

No real API/UI: Limited to a console-based simulation.