Parking Lot System

Requirements

Functional

Multiple floors, each with parking spots of different sizes
Support vehicle types: Motorcycle, Car, Bus
Assign nearest available spot matching vehicle size
Track entry/exit, calculate parking fee
Display available spots per floor/type

Non-Functional

Thread-safe (concurrent entry/exit)
Extensible (new vehicle types, payment methods)

Interview Approach

Start by clarifying requirements, then identify core entities, define relationships, and finally discuss concurrency and extensibility.

Class Diagram

Core Entities

ParkingLot (Singleton)
├── Floor[]
│   ├── ParkingSpot[]
│   │   ├── SmallSpot
│   │   ├── MediumSpot
│   │   └── LargeSpot
├── EntryPanel[]
├── ExitPanel[]
├── DisplayBoard[]
└── ParkingTicket[]

Vehicle (Abstract)
├── Motorcycle
├── Car
└── Bus

Implementation

Design Patterns Used

Pattern	Where
Singleton	ParkingLot — only one instance
Strategy	Fee calculation — different strategies for hourly, daily, monthly
Observer	DisplayBoard — updates when spot availability changes
Factory	Vehicle creation based on type

Fee Calculation (Strategy Pattern)

interface PricingStrategy {
  calculate(hours: number): number;
}

class HourlyPricing implements PricingStrategy {
  calculate(hours: number): number {
    return Math.ceil(hours) * 5; // $5/hour
  }
}

class DailyPricing implements PricingStrategy {
  calculate(hours: number): number {
    return Math.ceil(hours / 24) * 30; // $30/day
  }
}

Key Takeaways

Start with clear entities and relationships
Use Singleton for ParkingLot
Strategy for flexible fee calculation
Discuss thread safety for concurrent access
Keep it extensible for new vehicle types and spot sizes

Comments