Why Elevator, Floor, Request classes in LLD? - Purpose & Use Cases

The Big Idea

What if your elevator system could think and act smartly without you writing endless code for every button press?

The Scenario

Imagine managing a building with many floors and elevators by writing separate code for each floor and elevator without any structure.

Every time someone presses a button, you manually track which elevator should move where.

The Problem

This manual way is slow and confusing.

It's easy to make mistakes like sending two elevators to the same floor or missing a request.

As the building grows, the code becomes a tangled mess that's hard to fix or improve.

The Solution

Using Elevator, Floor, and Request classes organizes the system clearly.

Each class handles its own job: floors know their number, elevators know their position and state, and requests know where to go.

This makes the system easy to understand, update, and scale.

Before vs After

✗ Before

if button_pressed == 3:
  move_elevator_to(3)
elif button_pressed == 5:
  move_elevator_to(5)

✓ After

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

class Elevator:
  def move(self, request):
    print(f"Moving to floor {request.floor}")

What It Enables

It enables building smart, scalable elevator systems that handle many requests smoothly and reliably.

Real Life Example

In a busy office building, elevators must quickly respond to many people pressing buttons on different floors.

Using these classes helps the system decide which elevator to send without confusion or delay.

Key Takeaways

Manual tracking of elevator requests is error-prone and hard to maintain.

Elevator, Floor, and Request classes separate concerns clearly.

This structure makes the system scalable, reliable, and easier to improve.