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.

Primary Functions

Dispense item
1. Selects and dispenses various items depending on user order
Manage inventory
1. Keeps track of the inventory inside the vending machine
Process payment
1. Handles different types of payments including coins, cash, and cards
Alert for restock
1. Alerts for restock when inventory is low

Actors

Customer
1. Chooses an item
2. Pays for the item
3. Receives the item

Define Core Objects

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

Vending machine
1. Attributes
  1. List of slots
  2. Payment processor
  3. Inventory manager
2. Methods
  1. process_payment(PaymentType, Slot, money)
  2. dispense_item(slot_id)
  3. update_count(slot_id, new_count)
Inventory manager
1. Attributes
  1. Inventory count for each slot ID
2. Methods
  1. dispense_item(slot_id): returns success or failure
  2. update_count(slot_id, new_count): alerts when count is low
  3. restock_alert(AlertSystem, slot_id): alerts for low inventory
Alert system
1. Methods
  1. send_alert(slot_id)
Slot
1. Attributes
  1. Slot ID
  2. Cost
Payment processor
1. Methods
  1. process_payment(payment_type, Slot, money): returns receipt and change

Analyze Relationships

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

Vending machine contains multiple slots
1. Composition: Each slot is managed by the vending machine
Vending machine uses inventory manager
1. Composition: Alert system and item stock is managed by the vending machine's inventory manager
Vending machine uses payment processor
1. Composition or dependency: Vending machine has access to a payment processor
Inventory manager is linked to slots
1. Association: Inventory manager keeps track of stock count for each slot
Payment processor uses different payment_type
1. Dependency: process_payment calls payment_type statelessly and uses it
Inventory manager uses alert system
1. Depedency: temporarily uses alert system to sound an alert

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...

Slot is a base class with shared attributes, allowing multiple slot instances to be managed by the vending machine
PaymentMethod is a base class with a abstract method to be implemented by each different payment strategy (payment_type)

Design Patterns

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

Strategy
1. There are multiple payment strategies used by the payment processor

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.

from abc import ABC, abstractmethod
from typing import Dict, List
---------- Slot ----------
class Slot:
def init(self, slot_id: str, cost: int):
self.slot_id = slot_id
self.cost = cost
---------- Payment Strategy Interface ----------
class PaymentType(ABC):
@abstractmethod
def process(self, slot: Slot, money: int):
pass
class CardPayment(PaymentType):
def process(self, slot: Slot, money: int):
pass  # card-specific logic
class CashPayment(PaymentType):
def process(self, slot: Slot, money: int):
pass  # cash-specific logic
class CoinPayment(PaymentType):
def process(self, slot: Slot, money: int):
pass  # coin-specific logic
---------- Alert System ----------
class AlertSystem:
def send_alert(self, slot_id: str):
print(f"Alert: Restock needed for slot {slot_id}")
---------- Inventory Manager ----------
class InventoryManager:
def init(self, alert_system: AlertSystem):
self.inventory: Dict[str, int] = {}
self.alert_system = alert_system
def dispense_item(self, slot_id: str) -&gt; bool:
    pass

def update_count(self, slot_id: str, new_count: int):
    pass

def restock_alert(self, slot_id: str):
    self.alert_system.send_alert(slot_id)

---------- Payment Processor ----------
class PaymentProcessor:
def process_payment(self, payment_type: PaymentType, slot: Slot, money: int):
return payment_type.process(slot, money)
---------- Vending Machine ----------
class VendingMachine:
def init(self, slots: List[Slot], payment_processor: PaymentProcessor, inventory_manager: InventoryManager):
self.slots = {slot.slot_id: slot for slot in slots}
self.payment_processor = payment_processor
self.inventory_manager = inventory_manager
def process_payment(self, payment_type: PaymentType, slot: Slot, money: int):
    return self.payment_processor.process_payment(payment_type, slot, money)

def dispense_item(self, slot_id: str):
    pass

def update_count(self, slot_id: str, new_count: int):

self.inventory_manager.update_count(slot_id, new_count)

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.)...

Single Responsibility Principle
1. I made a separate class for the payment processor and inventory manager which has their own cohesive tasks relating to the system
Open/Closed Principle
1. Each payment strategy is extended from the base payment interface but does not modify its inherent function by implementing abstract methods
Liskov Substitution Principle
1. Each payment strategy must work as an expected payment method in payment processor
Dependency Inversion Principle
1. Class dependency for payment processor is not hardcoded, instead it is injected with a strategy that implements an abstraction

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
1. It is easy to scale horizontally by adding more instances and vertically by improving individual services. This is possible because the services follow single responsibility principle and are loosely coupled (modular services).
Extensibility
1. It is easy to extend functionalities through base classes. This makes it easier to inject new dependencies due to shared abstractions.

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...

Handle More Payment Types
1. Add support for mobile payments or digital wallets.
Improve Error Handling
1. Handle cases like out-of-stock items, failed payments, or machine jams more gracefully.
Track Usage Data
1. Add logging to track popular items and machine usage for restocking insights.
Offline Mode
1. Let the machine work temporarily if the network is down, and sync data later.
Security Features
1. Improve payment and inventory protection to prevent tampering or fraud.