Object-Oriented Design of an Elevator Control System

Design an elevator control system using object-oriented design. Identify the classes and their responsibilities, show how a button press becomes an elevator stopping at a floor, and implement the core of the control logic in TypeScript or another language of your choice. The round was reported only as an object-oriented elevator design problem. The setup below is a standard starting point to confirm with the interviewer, not reported requirements: - A building has floors numbered from a lowest to a highest floor, and one or more elevator cars. - Each floor has hall buttons for up and down. The top floor has only down, and the bottom floor has only up. - Each car has a panel of floor buttons. - A controller decides which car answers each hall call, and each car moves one floor at a time, stops, and opens its doors. ```hint Separate choosing a car from ordering stops Consider which object decides which car answers a hall call, and which object decides the order in which one car visits its stops. Keeping them separate makes each policy replaceable. ``` ### Constraints and Clarifications - Treat the physical elevator as a simulation that advances in steps, so the logic can be tested without real hardware or real time. - Scheduling goals, special operating modes, and capacity rules are open until clarified. Choose defaults and state them. ### Clarifying Questions - How many floors and cars should the design support, and must it work for a single car as well as a group of cars? - What should the scheduling optimize: passenger waiting time, travel time, or energy? - Are there capacity or weight limits, and what happens when a car is full? - Which special modes are needed, such as maintenance, emergency stop, or fire service? - What should happen to requests assigned to a car that goes out of service? ### What a Strong Answer Covers - Requirements stated first, with a clear separation between what is in scope and what is not. - A class model with clear responsibilities: the system or controller, cars, requests, direction, and the car's state, with the button panels as input sources. - A state model for a car, covering idle, moving up, moving down, doors open, and out of service, with valid transitions. - A stop-ordering policy for one car, and a separate policy for assigning cars to hall calls that can be swapped out. - Edge cases: duplicate presses, a request for the car's current floor, invalid floors, and a car failing with assigned requests. - How the design can be extended and tested. ### Follow-up Questions 1. How would you change car assignment for heavy morning traffic from the lobby going up? 2. How would you reassign a failed car's hall calls without losing any of them? 3. How would you add a rule that doors stay open while an obstruction sensor is triggered? 4. How would you test that no request waits forever?