Loading...
1. Floor Calls (Hall Requests): Passengers can press Up/Down buttons on any floor to summon an elevator. The system dispatches the most suitable elevator.
2. Cabin Requests (Destination Selection): Once inside an elevator, passengers select a destination floor, which is added to that elevator's internal stop schedule.
3. Multi-Elevator Coordination: The system manages N elevators across M floors, coordinating them via a central controller to minimize overall wait time and travel distance.
4. Door Control: Doors open automatically upon reaching a target floor and close after an idle timeout or before movement starts.
5. Maintenance Mode: Technicians can take an elevator out of service. Its pending requests are automatically drained and redistributed to other operational cars.
1. Low Latency: Dispatch decisions must complete in < 100ms for real-time responsiveness.
2. Fairness & Anti-Starvation: Scheduling algorithms must prevent distant floors or opposite directions from starving indefinitely.
3. Thread Safety: Concurrent button presses from floors/cabins and background movement loops must operate safely without race conditions or lost stops.
4. Scalability & Extensibility: Support swappable scheduling algorithms (LOOK, SSTF, Destination Dispatch) and scale from small buildings (2 cars) to high-rises (20+ cars).
Core Entities:
- Elevator: Physical cabin tracking currentFloor, direction (UP, DOWN, IDLE), state (MOVING, STOPPED, IDLE, MAINTENANCE), door, and stop sets (upStops, downStops).
- ElevatorController: Central dispatcher that holds references to all elevators, pending requests, and delegates algorithm selection to SchedulingStrategy.
- Floor: Represents a building floor with Up/Down hall call buttons.
- Request: Value object holding sourceFloor, destinationFloor, direction, and timestamp.
- Door: Encapsulates door state (isOpen), sensor safety, and auto-close timer.
- SchedulingStrategy (Interface): Defines selectElevator(request, elevators). Concrete: LookSchedulingStrategy, NearestCarStrategy (SSTF).
- ElevatorSystem: Facade entry point owning floors, elevators, and controller.
Relationships:
- Composition: ElevatorSystem OWNS Elevators and Floors (1-to-N). Elevator OWNS Door (1-to-1).
- Association: ElevatorController REFERENCES Elevators (rebooting controller does not destroy elevators).
- Strategy Pattern: ElevatorController DELEGATES car selection to SchedulingStrategy interface.
- Separation of Concerns: Floor does not talk directly to Elevator; it routes through ElevatorSystem -> ElevatorController -> SchedulingStrategy.
For each class, define the attributes (data) it will hold and the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation. Write your code in the code editor below.
1. Design Trade-offs:
- LOOK (SCAN) vs. SSTF (Nearest Car): SSTF minimizes immediate distance but suffers from starvation for distant floors. LOOK balances throughput and fairness by maintaining directional scans and granting massive bonuses (-1000) for on-path cars.
- Centralized Controller vs. Distributed Cars: Centralizing dispatch in ElevatorController decouples individual elevators, preventing tight coupling where every elevator would need to know the state of all other elevators.
- Separate Door Class: Rather than a boolean flag on Elevator, Door encapsulates safety sensors, obstacle detection, and auto-close timeouts, isolating hardware interaction from movement logic.
2. SOLID Principles Compliance:
- Single Responsibility: Elevator manages movement and stop execution; ElevatorController manages fleet dispatch; Door manages entry access; SchedulingStrategy encapsulates dispatch algorithms.
- Open/Closed: New scheduling strategies (e.g., ZoneBasedStrategy, DestinationDispatch) can be plugged in without modifying ElevatorController.
- Liskov Substitution: Any SchedulingStrategy implementation (LOOK, SSTF, FCFS) adheres to the selectElevator() contract and can be swapped at runtime.
- Interface Segregation: SchedulingStrategy interface exposes a single focused method: selectElevator().
- Dependency Inversion: ElevatorController depends on the SchedulingStrategy abstraction rather than concrete algorithm implementations.
3. Concurrency & Scalability:
- Thread-Safety: State transitions and stop queue updates are synchronized to ensure atomic Read-Then-Write operations (e.g. checking floor, removing stop, reversing direction).
- High-Rise Scaling (50+ floors): Implement Zone-Based Dispatch (dividing elevators into Low/Mid/High zones) to shrink the algorithm search space from O(N) to O(N/zones).
- Destination Dispatch: Grouping passengers heading to identical floors via lobby kiosks dramatically cuts total stops per trip.
4. Future Improvements:
- Weight & Overload Sensors: Prevent cabin movement when weight capacity is exceeded.
- Observer Pattern for Idle Events: Have elevators notify the controller immediately upon becoming IDLE instead of relying on periodic polling.
- Energy Optimization: Park idle elevators at peak-traffic floors (e.g., Lobby in the morning, top floors in the evening)..