Object-Oriented Design: Elevator System

📌 Problem Statement

"Design an elevator system for a multi-floor building that includes multiple elevators and efficiently handles user requests."

This is a classic OOD interview question. It tests your ability to model real-world systems using objects, encapsulate behaviors, manage state, and design interactions between components.

✅ Requirements

Functional Requirements

  • Support multiple elevators in a single building
  • Allow internal requests (user presses floor buttons inside the elevator)
  • Allow external requests (user presses up/down buttons on each floor)
  • Elevators should move intelligently: serve requests in the right order and direction
  • Support idle, moving, and door open/close states
  • Provide visual indicators of floor position and direction

Non-Functional Requirements

  • Handle concurrent requests safely
  • Be extensible (e.g., add priority floors, express elevators)
  • Optional: simulate real-time movement or event-driven behavior

🎯 Key Object-Oriented Concepts

  • Encapsulation: Each elevator manages its internal state independently
  • Inheritance/Interface Segregation: Common interfaces for requests or sensors
  • Polymorphism: Different scheduling strategies (e.g., FCFS, SCAN)
  • Responsibility Assignment: Clearly define which class owns what behavior

🧱 Core Classes and Responsibilities

Elevator

  • id: unique identifier
  • currentFloor: the floor the elevator is on
  • direction: up, down, or idle
  • status: moving, idle, or door open
  • requestQueue: list of floor requests
  • Methods: move(), openDoor(), closeDoor(), addRequest(floor)

ElevatorController

  • Manages all elevators
  • Assigns requests to the best elevator based on current state
  • Supports different scheduling algorithms
  • Methods: handleExternalRequest(floor, direction), assignElevator()

Request

  • Represents a floor request
  • Can be internal or external
  • Has direction and floor number
  • Helps distinguish between command origin

FloorPanel

  • Located on each floor
  • Has up/down buttons
  • Emits external requests to the controller

ElevatorPanel

  • Located inside each elevator
  • Contains buttons for each floor
  • Sends internal requests to the elevator

🔁 Elevator State & Movement

Elevators transition through states:

  • Idle → waiting for request
  • Moving → toward requested floor
  • Door Open → passenger entry/exit
  • Door Close → resume movement

Request queues must maintain ordering and avoid starvation.

⚙️ Scheduling Logic (ElevatorController)

Example policies:

  • Nearest Elevator: Send request to the closest available elevator
  • Same Direction Only: Only assign to elevators going in the same direction
  • Priority Queue: Use a priority queue based on distance and direction

This logic is encapsulated and can be swapped for more complex strategies later.

🔍 Additional Considerations

  • Concurrency: Use locks or queues to prevent race conditions
  • Error Handling: What if an elevator breaks mid-operation?
  • Simulation: Track timing of movements for each floor
  • Extensions:
    • Express elevators that skip some floors
    • VIP access for certain floors
    • Voice-based or touchscreen panels

🧠 Interviewer Evaluation Criteria

AreaWhat They’re Looking For
Class DesignLogical separation of concerns and responsibilities
OOP PrinciplesUsage of encapsulation, polymorphism, interfaces
State ManagementClear modeling of transitions and queue updates
ExtendabilityHow easy it is to add features (like priority floors)
Trade-offs DiscussionScheduling complexity, idle behavior, starvation risks

✅ Summary

Designing an elevator system is a comprehensive OOD exercise that involves:

  • State machines
  • Scheduling
  • Interaction between concurrent components
  • Real-world behavior simulation

An effective design clearly separates elevator logic from control logic and anticipates extensibility and fault tolerance.