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.

Practice

1. What is the primary role of the Request class in an elevator system?

easy

A. To store the floor number and direction of a user's request

B. To move the elevator between floors

C. To open and close the elevator doors

D. To track the number of elevators in the building

Solution

1. Step 1: Understand the purpose of Request class

   The Request class holds information about where a user wants to go and in which direction.

2. Step 2: Compare roles of other classes

   Elevator moves and Floor represents building levels, but Request stores user input details.

3. Final Answer:

   To store the floor number and direction of a user's request -> Option A

4. Quick Check:

   Request = user floor and direction [OK]

Hint: Request class holds user floor and direction info [OK]

Common Mistakes:

• Confusing Request with Elevator movement
• Thinking Request controls doors
• Mixing Request with Floor class responsibilities

2. Which of the following is the correct way to define a Request class constructor in Python to store floor and direction?

easy

A. def Request(floor, direction): self.floor = floor; self.direction = direction

B. def __init__(self, floor, direction): self.floor = floor; self.direction = direction

C. def __init__(floor, direction): self.floor = floor; self.direction = direction

D. def __init__(self): floor = None; direction = None

Solution

1. Step 1: Recall Python constructor syntax

   Python constructors use def __init__(self, ...) and assign attributes with self.attribute = value.

2. Step 2: Check each option

   def __init__(self, floor, direction): self.floor = floor; self.direction = direction correctly uses self and assigns floor and direction. Others miss self or parameters.

3. Final Answer:

   def __init__(self, floor, direction): self.floor = floor; self.direction = direction -> Option B

4. Quick Check:

   Constructor with self and attributes = def __init__(self, floor, direction): self.floor = floor; self.direction = direction [OK]

Hint: Python constructors need self parameter and attribute assignment [OK]

Common Mistakes:

• Omitting self parameter
• Using class name as constructor
• Not assigning attributes to self

3. Given this Python snippet, what will be printed?

class Request:
    def __init__(self, floor, direction):
        self.floor = floor
        self.direction = direction

r = Request(5, 'up')
print(r.floor, r.direction)

medium

A. Error: missing self

B. floor direction

C. 5 up

D. None None

Solution

1. Step 1: Understand object creation and attribute assignment

   The Request object r is created with floor=5 and direction='up'. These are stored in attributes.

2. Step 2: Print attributes

   Printing r.floor and r.direction outputs 5 and 'up' respectively.

3. Final Answer:

   5 up -> Option C

4. Quick Check:

   Attributes print as assigned = 5 up [OK]

Hint: Print object attributes to see stored values [OK]

Common Mistakes:

• Expecting attribute names instead of values
• Confusing class variables with instance variables
• Assuming error without checking code carefully

4. Identify the error in this Elevator class snippet:

class Elevator:
    def __init__(self, current_floor):
        self.current_floor = current_floor

    def move_to(self, floor):
        current_floor = floor

medium

A. Indentation error in move_to method

B. Missing return statement in move_to method

C. Constructor should not have parameters

D. The move_to method updates a local variable, not the elevator's floor

Solution

1. Step 1: Analyze move_to method

   The method assigns current_floor = floor without self., so it changes a local variable only.

2. Step 2: Understand instance variable update

   To update the elevator's floor, it should be self.current_floor = floor.

3. Final Answer:

   The move_to method updates a local variable, not the elevator's floor -> Option D

4. Quick Check:

   Missing self. means local variable used [OK]

Hint: Use self. to update instance variables inside methods [OK]

Common Mistakes:

• Forgetting self. prefix
• Thinking return is needed to update state
• Assuming indentation is wrong without checking

5. In designing an elevator system with Elevator, Floor, and Request classes, which approach best handles multiple simultaneous requests efficiently?

hard

A. Use a priority queue in Elevator to process requests by nearest floor and direction

B. Process requests in the order they arrive without sorting

C. Assign each request to a random elevator immediately

D. Ignore direction and always move elevators to the highest requested floor first

Solution

1. Step 1: Understand multiple request handling

   Efficient elevator systems prioritize requests to minimize travel and wait time.

2. Step 2: Evaluate options for request processing

   Using a priority queue to pick nearest floors and matching direction optimizes movement. Others cause inefficiency or randomness.

3. Final Answer:

   Use a priority queue in Elevator to process requests by nearest floor and direction -> Option A

4. Quick Check:

   Priority queue for nearest requests = Use a priority queue in Elevator to process requests by nearest floor and direction [OK]

Hint: Prioritize nearest requests with direction for efficient elevator movement [OK]

Common Mistakes:

• Ignoring direction leads to inefficient routes
• Random assignment causes delays
• Processing requests strictly by arrival order wastes time