Design a Parking Lot System

Problem Overview

A multi-level parking lot needs to admit vehicles into free spots, track which vehicles are currently parked, and free a spot back up when a vehicle leaves. This is a classic object-oriented design interview problem: unlike an algorithmic question, there's no single right function to write — you're designing a small set of collaborating classes and being graded on whether the system they form actually behaves correctly.

Functional Requirements

• Park an incoming vehicle in any compatible free spot, and return a ticket identifying that parking session.
• Reject a vehicle when no compatible spot is free (return null - None in Python - rather than throwing).
• Free a vehicle's spot given its ticket, and correctly reject an unknown/already-used ticket.
• Report how many spots of a given size are currently free.
• A vehicle fits exactly one spot size: MOTORCYCLE -> SMALL, CAR -> MEDIUM, BUS -> LARGE.
• Each ticket is unique and frees its spot once; using it again returns false (False in Python).

Project Layout

• parkinglot/model/Vehicle.java (fixed) — a vehicle's type and license plate.
• parkinglot/model/ParkingSpot.java (fixed) — a single spot's size and occupied state.
• parkinglot/ParkingLot.java (you implement) — the public API under test; owns the collection of spots and the mapping from ticket to occupied spot. Keep its constructor and public methods.
• parkinglot/Main.java — a demo you can change freely; Run prints its output.
• Your own classes can go anywhere under parkinglot/ except parkinglot/tests/ — for example an allocation strategy in parkinglot/strategy/.
• In Python the same layout is made of modules: parkinglot/model/vehicle.py and parking_spot.py (fixed - the enums are VehicleType and SpotSize), parkinglot/parking_lot.py (yours: park_vehicle, unpark_vehicle, available_spots) and parkinglot/main.py (the demo).

Run executes the sample tests in parkinglot/tests/ParkingLotSampleTest.java (Python: parkinglot/tests/sample_test.py) and shows each failure's message. Submit runs the hidden suite — pass/fail per test only — and is what's scored.

Patterns to Apply

• Encapsulation: ParkingLot should own spot-allocation logic entirely — callers never touch a ParkingSpot's occupied flag directly.
• A simple allocation strategy (first free compatible spot) is enough here; a Strategy pattern swap-in (e.g. nearest-spot, size-optimal) is a natural follow-up, not required.

Follow-up Questions (for discussion, not graded)

• How would you support multiple entry gates operating concurrently without double-allocating the same spot?
• How would per-duration pricing/billing extend this design without ParkingLot needing to know about payment details?
• How would you generalize ParkingSpot.Size matching if a vehicle could fit in multiple spot sizes (e.g. a motorcycle fitting in any size)?

• Do not change the signatures of ParkingLot's public methods, or of Vehicle/ParkingSpot - the hidden tests are written against them exactly as given.
• Assume single-threaded access - concurrency is a follow-up discussion question, not graded.