Elevator, Floor, Request classes in LLD - System Design Guide

Problem Statement

When designing an elevator control system, mixing responsibilities in one class leads to confusing code and hard-to-maintain logic. Without clear separation, handling floors, elevator states, and requests becomes tangled, causing bugs and difficulty in extending features.

Solution

Separate the system into three classes: Elevator to manage elevator state and movement, Floor to represent each floor's properties, and Request to encapsulate user requests. This clear division helps organize code, making it easier to add features like request queues or multiple elevators.

Architecture

┌───────────┐       ┌───────────┐       ┌────────────┐
│  Request  │──────▶│  Elevator │──────▶│   Floor    │
└───────────┘       └───────────┘       └────────────┘

This diagram shows how Request objects are sent to the Elevator, which then interacts with Floor objects to move and serve requests.

Trade-offs

✓ Pros

→

Clear separation of concerns improves code readability and maintainability.

→

Easier to extend system with new features like multiple elevators or priority requests.

→

Simplifies testing each component independently.

✗ Cons

→

More classes increase initial complexity for very simple elevator simulations.

→

Requires careful coordination between classes to avoid tight coupling.

→

May introduce overhead in communication between objects.

Use when building elevator control systems with multiple floors and requests, especially if planning to extend features or maintain code long-term.

Avoid if building a very simple elevator simulation with only one floor and no request handling, where a single class suffices.

Real World Examples

Amazon

Amazon uses modular elevator control software in warehouses to manage multiple elevators efficiently, separating request handling from elevator movement logic.

Google

Google's office buildings use elevator control systems that separate floor sensors, elevator states, and user requests to optimize traffic flow.

Code Example

The before code mixes floor requests as integers inside the Elevator class, making it hard to extend. The after code separates Request and Floor into their own classes, so Elevator handles only movement and request management, improving clarity and extensibility.

LLD

### Before: Monolithic Elevator Class (no separation)
class Elevator:
    def __init__(self):
        self.current_floor = 0
        self.requests = []

    def request_floor(self, floor):
        self.requests.append(floor)

    def move(self):
        while self.requests:
            next_floor = self.requests.pop(0)
            print(f"Moving from {self.current_floor} to {next_floor}")
            self.current_floor = next_floor


### After: Separate Elevator, Floor, Request Classes
class Request:
    def __init__(self, floor_number):
        self.floor_number = floor_number

class Floor:
    def __init__(self, number):
        self.number = number

class Elevator:
    def __init__(self):
        self.current_floor = 0
        self.requests = []

    def add_request(self, request):
        self.requests.append(request)

    def move(self):
        while self.requests:
            request = self.requests.pop(0)
            print(f"Moving from {self.current_floor} to {request.floor_number}")
            self.current_floor = request.floor_number

Alternatives

Monolithic Elevator Class

Combines elevator state, floor info, and requests in one class without separation.

Use when: Choose when building very simple or prototype elevator systems with minimal features.

Event-Driven Elevator System

Uses event queues and listeners instead of direct method calls between classes.

Use when: Choose when building highly scalable or distributed elevator control systems.

Summary

Separating Elevator, Floor, and Request into distinct classes improves code clarity and maintainability.

This design allows easier extension for features like multiple elevators or request prioritization.

Clear class responsibilities help avoid bugs and simplify testing.