Object-Oriented Design and Code for a Parking Lot System

Design and implement the core of a parking lot system with object-oriented design, in code. The round is a coding exercise: the interviewer expects classes and working methods, not only a diagram, and may ask you to explain each design choice as you write it. The problem is given only as "a parking lot", so pinning down the requirements is part of the task. A reasonable baseline to propose and confirm: - The lot has one or more levels, and each level has numbered spots of a few sizes. - Vehicles of a few types arrive, and each needs a spot it fits in; when a vehicle leaves, its spot becomes free again. - Entering produces a record of the stay, and leaving computes what the driver owes. - Staff can see how many spots of each size are free. Implement the classes, a `park` operation for an arriving vehicle, a `leave` operation for a departing one, and the rule that chooses a spot. ```hint Start from the two operations List the entities first, then decide which single object owns arriving and leaving, and what state it must hold so that both operations stay correct. ``` ```hint Avoid searching the whole lot Scanning every spot on each arrival works for a toy lot. Think about what you could keep up to date on every arrival and departure so that finding a suitable free spot does not depend on the size of the lot. ``` ### Constraints and Clarifications - No requirements beyond "parking lot" are given. State each assumption explicitly and keep it in one place in the code, so it is easy to change. - A working `park` and `leave` with a clear allocation rule matters more than a long feature list. Add pricing, displays or extra vehicle types after the core works. ### Clarifying Questions - Which vehicle types and spot sizes exist? May a smaller vehicle use a larger spot, and may a large vehicle need several spots? - How should a spot be chosen: lowest level first, nearest to an entrance, or the smallest spot that fits? - Is payment in scope, and if so, what is the pricing rule (per started hour, by vehicle type, with a daily maximum)? - What should happen when no suitable spot is free, when the same plate tries to enter twice, or when a ticket is lost? - Is there one entrance, or several admitting vehicles at the same time? - Is an in-memory model enough, or must the state survive a restart? ### What a Strong Answer Covers - Requirements scoped quickly, with the assumptions stated - A small class model (vehicle, spot, ticket, pricing, the lot) in which each piece of mutable state has exactly one owner - An explicit spot-allocation policy and a data structure that makes it efficient - Correct `park` and `leave`, including a full lot, a duplicate entry, and an unknown or reused ticket - Extension points through composition, such as pluggable pricing, and money kept in integer units - Awareness that several entrances can race for the same spot - Readable, working code, with each design choice explained when asked ### Follow-up Questions - Some vehicles need several adjacent large spots on the same level. How do the model and the allocation change? - Two entrances try to give the last free spot to two cars at the same moment. How do you prevent a double assignment in memory, and with a shared database? - Add a display at the entrance showing free spots per level and size. How does it stay correct as vehicles come and go? - Pricing changes to include a daily maximum and a separate night rate. Which classes change, and which stay untouched?