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.