Design Parking Lot

1. Requirements & Assumptions

Functional Requirements

• The parking lot has multiple floors, and each floor contains multiple parking spots.
• Supports different vehicle types: Cars, Trucks, Motorcycles, and Vans.
• Supports different parking spot types: Compact, Large, Handicapped, and Motorcycle.
• Vehicles can only park in spots that accommodate their type (e.g., Trucks can only park in Large spots).
• The system must calculate parking fees based on duration and vehicle type when unparking.
• Supports different payment/pricing strategies (e.g., hourly rate, flat rate).

Non-Functional Requirements

• Thread Safety: Multiple vehicles might attempt to park or unpark simultaneously. The system must prevent double-booking of spots.
• Extensibility: Adding new spot types or pricing strategies should be possible without modifying existing core logic.

Assumptions

• One vehicle occupies exactly one parking spot.
• A vehicle cannot span multiple spots.
• Payment is handled at exit gates.

2. Entities, Responsibilities & Relationships

• ParkingLot (Singleton): Coordinates floors, gates, and system-wide configurations.
• ParkingFloor: Manages parking spots on a specific level and tracks availability.
• ParkingSpot: Holds vehicle references and verifies compatibility.
• Vehicle (Abstract): Base class representing vehicles (Car, Truck, Motorcycle).
• ParkingTicket: Stores ticket details (issue time, license plate, spot ID) to calculate fees.
• PricingStrategy (Strategy Pattern): Abstract interface for calculating rates dynamically based on duration and vehicle type.

3. Diagrams

UML Class Diagram

Sequence Diagram: Parking a Vehicle

4. Design Decisions

• Strategy Pattern for Fees: We decoupled rate calculation into a PricingStrategy interface, allowing us to change pricing rules (e.g., peak-hour pricing, weekend flat rates) without modifying ParkingLot.
• Synchronized Allocation: To prevent double-booking, the search and park phase on each floor is synchronized, guaranteeing thread safety.
• Loose Coupling: ParkingSpot evaluates vehicle compatibility using polymorphism rather than hardcoding checks inside the floor class.

5. Step-by-Step Implementation

1. Create enums for VehicleType and ParkingSpotType.
2. Define the abstract Vehicle class and concrete subclasses (Car, Motorcycle, etc.).
3. Implement ParkingSpot with compatibility checks.
4. Implement ParkingFloor to group spots and manage availability.
5. Define the PricingStrategy interface and implement an hourly pricing strategy.
6. Create the ParkingLot coordinator to manage tickets, park/unpark operations, and pricing.

6. Complete Code

7. Test Cases & Verification

• Test Case 1: Simple Parking: Park a Car on Floor 1. Verify that the system assigns the correct compact spot and issues a ticket.
• Test Case 2: Multi-floor Overflow: Fill Floor 1 spots and verify that a new vehicle is parked on Floor 2.
• Test Case 3: Vehicle Type Mismatch: Try to park a Truck in a Motorcycle spot. Verify that the request is rejected.

8. Scalability & SOLID Improvements

• SOLID - Open/Closed Principle: The spot compatibility checks are encapsulated inside ParkingSpot using polymorphism. If you introduce a new vehicle type (e.g., ElectricCar), you do not need to modify the ParkingFloor logic.
• Scalability - Segmented Floor Locks: Instead of synchronizing operations on the entire ParkingLot object, we synchronize on individual ParkingFloor objects. This allows vehicles to park on Floor 1 and Floor 2 concurrently without thread contention.

9. Production Considerations

• Database Synchronization: In production, tickets and spot occupancies must be persisted in a database (e.g., using PostgreSQL with optimistic locking to prevent concurrent double-booking).
• Offline Resiliency: Exit gates must have local pricing engines to calculate fees and process payments even if connection to the central database server is temporarily lost.

10. Next Lesson Preview

In the next case study, we will design a Vending Machine using the State Pattern. We will study state-dependent behaviors, coin validations, and inventory updates!