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

Problem Statement

Without clear class identification, the system becomes confusing and hard to maintain. Developers may mix responsibilities, causing bugs and making future changes risky and slow.

Solution

Identify distinct classes representing real-world entities like ParkingLot, Floor, Spot, and Vehicle. Each class holds its own data and behavior, making the system organized and easier to extend or debug.

Architecture

┌────────────┐       ┌───────────┐       ┌───────────┐       ┌───────────┐
│ ParkingLot │──────▶│   Floor   │──────▶│   Spot    │       │  Vehicle  │
└────────────┘       └───────────┘       └───────────┘       └───────────┘
       │                  │                  │                  │
       │                  │                  │                  │
       └──────────────────────────────────────────────────────────┘

This diagram shows the relationship between ParkingLot, Floor, Spot, and Vehicle classes. ParkingLot contains Floors; Floors contain Spots; Spots can be occupied by Vehicles.

Trade-offs

✓ Pros

→

Clear separation of concerns improves code readability and maintainability.

→

Easier to add new features like different vehicle types or spot sizes.

→

Simplifies debugging by isolating responsibilities to specific classes.

✗ Cons

→

Initial design takes more time to identify and define classes properly.

→

May introduce more classes than a simple script, increasing complexity for very small projects.

→

Requires careful planning to avoid tight coupling between classes.

Use when designing systems that model real-world entities with distinct roles, especially when the system will grow or require maintenance.

Avoid for very simple scripts or prototypes where overhead of multiple classes outweighs benefits.

Real World Examples

Uber

Models vehicles, parking spots, and locations distinctly to manage ride assignments and parking efficiently.

Airbnb

Separates properties, rooms, and guests into classes to handle bookings and availability cleanly.

LinkedIn

Uses clear class structures for users, connections, and messages to maintain scalable social network features.

Code Example

The before code mixes all data in one dictionary, making it hard to manage or extend. The after code defines clear classes for Vehicle, Spot, Floor, and ParkingLot, each with its own data and methods. This separation makes the system easier to understand, maintain, and extend.

LLD

### Before: No clear classes, everything mixed
parking_data = {
    'floors': 3,
    'spots_per_floor': 10,
    'occupied_spots': [(1, 5), (2, 3)],  # floor, spot
    'vehicles': ['car1', 'car2']
}

### After: Clear class identification
class Vehicle:
    def __init__(self, license_plate):
        self.license_plate = license_plate

class Spot:
    def __init__(self, spot_number):
        self.spot_number = spot_number
        self.vehicle = None
    def park_vehicle(self, vehicle):
        self.vehicle = vehicle
    def remove_vehicle(self):
        self.vehicle = None

class Floor:
    def __init__(self, floor_number, spots_count):
        self.floor_number = floor_number
        self.spots = [Spot(i+1) for i in range(spots_count)]

class ParkingLot:
    def __init__(self, floors_count, spots_per_floor):
        self.floors = [Floor(i+1, spots_per_floor) for i in range(floors_count)]

    def park(self, vehicle):
        for floor in self.floors:
            for spot in floor.spots:
                if spot.vehicle is None:
                    spot.park_vehicle(vehicle)
                    return (floor.floor_number, spot.spot_number)
        return None

Alternatives

Entity-Attribute-Value (EAV)

Stores all data in generic tables or classes with flexible attributes instead of fixed classes.

Use when: Choose when the data model is highly dynamic and cannot be predicted upfront.

Procedural Design

Uses functions and data structures without strict class boundaries.

Use when: Choose for very small or one-off scripts where object orientation adds unnecessary complexity.

Summary

Identifying clear classes helps organize code by real-world entities and responsibilities.

Well-defined classes improve maintainability, readability, and ease of extension.

Avoid mixing unrelated data and behavior to prevent confusion and bugs.

Practice

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