Bird
Raised Fist0
LLDsystem_design~25 mins

Class identification (ParkingLot, Floor, Spot, Vehicle) in LLD - System Design Exercise

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Parking Lot Management System
Design the core classes and their relationships to model the parking lot, floors, spots, and vehicles. Out of scope: payment processing, user authentication, mobile app UI.
Functional Requirements
FR1: Allow vehicles to enter and find a parking spot
FR2: Support multiple floors with multiple spots per floor
FR3: Track which spots are occupied and which are free
FR4: Support different vehicle types (car, motorcycle, truck)
FR5: Allow vehicles to leave and free up spots
FR6: Provide a way to check availability of spots
Non-Functional Requirements
NFR1: System should handle up to 1000 vehicles simultaneously
NFR2: Spot allocation and release should be done within 200ms
NFR3: System should be designed for easy extension (e.g., new vehicle types)
NFR4: Maintain consistency of spot occupancy status
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
ParkingLot class to represent the entire parking structure
Floor class to represent each level in the parking lot
Spot class to represent individual parking spots
Vehicle class hierarchy for different vehicle types
Spot allocation and release logic
Design Patterns
Factory pattern for creating different vehicle types
Composite pattern for ParkingLot containing Floors and Spots
Strategy pattern for different spot allocation algorithms
Observer pattern to notify when spots become free or occupied
Reference Architecture
ParkingLot
  ├─ Floor 1
  │    ├─ Spot 1 (Car)
  │    ├─ Spot 2 (Motorcycle)
  │    └─ Spot 3 (Truck)
  ├─ Floor 2
  │    ├─ Spot 1 (Car)
  │    └─ Spot 2 (Car)
  └─ Floor N
       └─ Spot M

Vehicle
  ├─ Car
  ├─ Motorcycle
  └─ Truck
Components
ParkingLot
Class
Represents the entire parking lot containing multiple floors
Floor
Class
Represents a single floor in the parking lot containing multiple spots
Spot
Class
Represents an individual parking spot with a type and occupancy status
Vehicle
Abstract Class or Interface
Base class for different vehicle types
Car, Motorcycle, Truck
Classes inheriting Vehicle
Specific vehicle types with possible unique attributes
Request Flow
1. Vehicle arrives and requests a spot from ParkingLot
2. ParkingLot delegates request to Floors to find an available Spot matching vehicle type
3. Floor checks its Spots and returns an available Spot if any
4. ParkingLot assigns the Spot to the Vehicle and marks it occupied
5. When Vehicle leaves, ParkingLot marks the Spot as free
6. Availability queries check Floors and Spots for free spots
Database Schema
Entities: - ParkingLot (id, name, location) - Floor (id, parking_lot_id, floor_number) - Spot (id, floor_id, spot_type, is_occupied) - Vehicle (id, vehicle_type, license_plate) Relationships: - ParkingLot 1:N Floor - Floor 1:N Spot - Spot 0..1 Vehicle (occupied by one vehicle or none)
Scaling Discussion
Bottlenecks
Spot allocation latency increases with large number of floors and spots
Concurrency issues when multiple vehicles try to occupy the same spot
Tracking availability in real-time for large parking lots
Solutions
Use efficient data structures (e.g., priority queues) to quickly find free spots
Implement locking or atomic operations to prevent double allocation
Cache availability status and update asynchronously to reduce load
Interview Tips
Time: 10 minutes to clarify requirements and ask questions, 20 minutes to design classes and relationships, 10 minutes to discuss scaling and improvements, 5 minutes for summary
Explain class responsibilities clearly
Show understanding of relationships and associations
Discuss how to handle different vehicle and spot types
Mention concurrency and consistency considerations
Talk about extensibility for future features

Practice

(1/5)
1. Which class in a parking system is responsible for managing multiple floors?
easy
A. ParkingLot
B. Floor
C. Spot
D. Vehicle

Solution

  1. Step 1: Understand the role of ParkingLot

    The ParkingLot class represents the entire parking area and manages multiple floors within it.
  2. Step 2: Compare with other classes

    Floor manages spots on a single level, Spot represents a single parking space, and Vehicle represents the car or bike.
  3. Final Answer:

    ParkingLot -> Option A
  4. Quick Check:

    ParkingLot manages floors = C [OK]
Hint: ParkingLot holds floors; floors hold spots [OK]
Common Mistakes:
  • Confusing Floor as managing multiple floors
  • Thinking Spot manages floors
  • Assigning Vehicle to manage floors
2. Which of the following is the correct way to represent a parking spot in a class diagram?
easy
A. class Vehicle { int spotNumber; boolean isOccupied; }
B. class Spot { int spotNumber; boolean isOccupied; }
C. class Floor { int spotNumber; boolean isOccupied; }
D. class ParkingLot { int spotNumber; boolean isOccupied; }

Solution

  1. Step 1: Identify the class representing a parking spot

    The Spot class should have attributes like spotNumber and isOccupied to represent a parking space.
  2. Step 2: Check other classes for correctness

    Vehicle represents cars, Floor represents a level, and ParkingLot represents the whole area, so they should not have spotNumber or isOccupied attributes.
  3. Final Answer:

    class Spot { int spotNumber; boolean isOccupied; } -> Option B
  4. Quick Check:

    Spot class holds spot info = A [OK]
Hint: Spot class holds spot details like number and occupancy [OK]
Common Mistakes:
  • Assigning spot attributes to Vehicle
  • Putting spotNumber in Floor or ParkingLot
  • Confusing class roles in diagram
3. Given the following code snippet, what will be the output?
class Vehicle {
  String licensePlate;
  Vehicle(String plate) { licensePlate = plate; }
}
class Spot {
  Vehicle parkedVehicle;
  boolean isOccupied() { return parkedVehicle != null; }
}
Spot spot = new Spot();
System.out.println(spot.isOccupied());
medium
A. true
B. Compilation error
C. null
D. false

Solution

  1. Step 1: Analyze Spot initialization

    The Spot object is created but parkedVehicle is not assigned, so it defaults to null.
  2. Step 2: Evaluate isOccupied method

    isOccupied returns true if parkedVehicle is not null; here it is null, so it returns false.
  3. Final Answer:

    false -> Option D
  4. Quick Check:

    parkedVehicle is null, so isOccupied() = false [OK]
Hint: Unassigned vehicle means spot is free (false) [OK]
Common Mistakes:
  • Assuming default boolean is true
  • Confusing null with false
  • Expecting compilation error due to missing constructor
4. Identify the error in this class design snippet:
class Floor {
  List<Spot> spots;
  void addSpot(Spot s) {
    spots.add(s);
  }
}
medium
A. Spot class should be inside Floor class
B. Method addSpot should return boolean
C. spots list is not initialized before adding
D. Floor class should not have spots list

Solution

  1. Step 1: Check initialization of spots list

    The spots list is declared but not initialized, so calling add on it will cause a runtime error.
  2. Step 2: Validate other options

    Returning boolean is optional, Spot class can be separate, and Floor should have spots list to manage spots.
  3. Final Answer:

    spots list is not initialized before adding -> Option C
  4. Quick Check:

    Uninitialized list causes error = A [OK]
Hint: Always initialize lists before use [OK]
Common Mistakes:
  • Ignoring list initialization
  • Thinking method return type matters here
  • Believing Spot must be nested class
5. You want to design a system where each Vehicle can only park in a Spot that matches its size (e.g., small, medium, large). Which class design change best supports this requirement?
hard
A. Add a size attribute to both Vehicle and Spot classes and check compatibility before parking
B. Add a size attribute only to Vehicle class and ignore Spot size
C. Add a size attribute only to Spot class and ignore Vehicle size
D. Remove size attributes and allow any Vehicle to park anywhere

Solution

  1. Step 1: Understand size matching requirement

    Both Vehicle and Spot need size attributes to compare and ensure compatibility.
  2. Step 2: Evaluate options

    Ignoring size in either class prevents proper matching; removing size ignores requirement.
  3. Final Answer:

    Add a size attribute to both Vehicle and Spot classes and check compatibility before parking -> Option A
  4. Quick Check:

    Size match needs attributes in both classes = B [OK]
Hint: Both Vehicle and Spot need size info to match [OK]
Common Mistakes:
  • Adding size to only one class
  • Ignoring size and allowing any parking
  • Confusing attribute placement