Codemia | Master System Design Interviews Through Active Practice

My Solution for Design a Parking Lot with Score: 9/10

by nectar4678

Requirements

The parking lot system will be used to manage vehicle parking across multiple floors. The system will cater to different types of vehicles, including cars, bikes, and trucks, with varying parking spot sizes. The main functionalities of the system include:

Parking Spot Assignment:

The system should assign parking spots based on vehicle size and spot availability.
It should manage spot reservations and ensure optimal usage of available space.

Spot Availability Checking:

Users and the system should be able to check the availability of parking spots in real-time.
The system should provide an interface for users to view available spots across different floors.

Fee Calculation:

The system should calculate parking fees based on the duration of the parking session.
Different rates may apply based on the vehicle type (e.g., bikes, cars, trucks) and parking spot (e.g., premium, regular).

User Roles and Permissions:

The system will have different roles, including Admin, Attendant, and User (vehicle owner).
Admins can configure parking lot settings, including pricing and floor management.
Attendants can check-in/check-out vehicles and manage spot assignments.
Users can reserve spots, check availability, and view their parking history.

Support for Multiple Floors:

The system should manage parking spots across multiple floors, allowing users to park on any available floor.
Floor-specific features might include reserved spots for electric vehicles, handicapped spaces, and charging stations.

Define Core Objects

Based on the requirements and use cases we've identified, the main objects of the system will be:

Analyze Relationships

Now that we've defined the core objects, let's analyze how these objects will interact with each other to fulfill the use cases of the parking lot system.

ParkingLot and ParkingFloor:
- The ParkingLot contains multiple ParkingFloor objects. It manages the overall parking facility and delegates the task of finding an available spot to the appropriate floor.
ParkingFloor and ParkingSpot:
- Each ParkingFloor contains multiple ParkingSpot objects. The floor finds and assigns an available spot to a vehicle based on its size.
ParkingSpot and Vehicle:
- A ParkingSpot is either occupied by a Vehicle or is vacant. When occupied, the spot stores a reference to the vehicle.
Vehicle and Ticket:
- When a vehicle is parked, a Ticket is generated, recording the entry time, the assigned spot, and the vehicle. The ticket is used to calculate the parking fee.
Ticket and Payment:
- A Payment is made for a Ticket. The payment records the amount paid and marks the ticket as settled.
User and ParkingLot System:
- Users interact with the system based on their roles (Admin, Attendant, Regular User), performing actions like spot reservation, vehicle check-in/out, and viewing parking history.

Establish Hierarchy

Class Hierarchy:

ParkingSpot:
- We'll create a base class called ParkingSpot that will contain common attributes like spotId, size, and isOccupied.
- We can then create subclasses for different types of parking spots if needed, such as CompactSpot, LargeSpot, and HandicappedSpot, each inheriting from ParkingSpot.
Vehicle:
- A base class Vehicle will represent general attributes like licensePlate and size.
- Subclasses like Car, Bike, and Truck can inherit from Vehicle to handle vehicle-specific details.
User:
- The User class will serve as a base class with common attributes like userId, name, and role.
- Subclasses such as Admin, Attendant, and RegularUser can inherit from User to implement role-specific behaviors.
Ticket and Payment:
- These classes do not require a hierarchical structure, as they are specific to their tasks. However, they could implement common interfaces if the system were to grow, supporting different types of payments or ticket systems.

Design Patterns

Factory Pattern

This pattern can be used to instantiate different types of ParkingSpot and Vehicle objects. For example, based on the vehicle type (car, bike, truck), the factory can create the appropriate Vehicle object.

public class VehicleFactory {
    public static Vehicle createVehicle(String type, String licensePlate) {
        switch(type.toLowerCase()) {
            case "car":
                return new Car(licensePlate);
            case "bike":
                return new Bike(licensePlate);
            case "truck":
                return new Truck(licensePlate);
            default:
                throw new IllegalArgumentException("Unknown vehicle type");
        }
    }
}

Singleton Pattern

The ParkingLot can be a singleton, ensuring that there is only one instance managing the entire parking facility.

public class ParkingLot {
    private static ParkingLot instance;
    
    private ParkingLot() {
        // Initialize ParkingLot
    }
    
    public static synchronized ParkingLot getInstance() {
        if (instance == null) {
            instance = new ParkingLot();
        }
        return instance;
    }
}

Strategy Pattern

This can be applied for calculating parking fees. Different strategies can be implemented based on vehicle type, parking duration, or special discounts.

public interface FeeStrategy {
    double calculateFee(Ticket ticket);
}

public class RegularFeeStrategy implements FeeStrategy {
    public double calculateFee(Ticket ticket) {
        // Basic fee calculation
    }
}

public class PremiumFeeStrategy implements FeeStrategy {
    public double calculateFee(Ticket ticket) {
        // Premium fee calculation
    }
}

public class Ticket {
    private FeeStrategy feeStrategy;
    
    public void setFeeStrategy(FeeStrategy feeStrategy) {
        this.feeStrategy = feeStrategy;
    }
    
    public double calculateFee() {
        return feeStrategy.calculateFee(this);
    }
}

Observer Pattern

This can be used to notify users (Admin, Attendant) when certain events occur, such as a parking spot becoming available or a payment being processed.

public interface ParkingObserver {
    void update(String eventType, ParkingSpot spot);
}

public class ParkingAttendant implements ParkingObserver {
    public void update(String eventType, ParkingSpot spot) {
        // Handle event, e.g., notify about spot availability
    }
}

public class ParkingSpot {
    private List<ParkingObserver> observers = new ArrayList<>();
    
    public void addObserver(ParkingObserver observer) {
        observers.add(observer);
    }
    
    public void removeObserver(ParkingObserver observer) {
        observers.remove(observer);
    }
    
    public void notifyObservers(String eventType) {
        for (ParkingObserver observer : observers) {
            observer.update(eventType, this);
        }
    }
}

Define Class Members (write code)

ParkingLot

public class ParkingLot {
    private static ParkingLot instance;
    private List<ParkingFloor> floors;
    private int totalSpots;
    private int availableSpots;

    private ParkingLot() {
        this.floors = new ArrayList<>();
    }

    public static synchronized ParkingLot getInstance() {
        if (instance == null) {
            instance = new ParkingLot();
        }
        return instance;
    }

    public void addFloor(ParkingFloor floor) {
        floors.add(floor);
        totalSpots += floor.getTotalSpots();
        availableSpots += floor.getAvailableSpots();
    }

    public ParkingSpot findAvailableSpot(Vehicle vehicle) {
        for (ParkingFloor floor : floors) {
            ParkingSpot spot = floor.findAvailableSpot(vehicle);
            if (spot != null) return spot;
        }
        return null; // No spot available
    }

    public void releaseSpot(ParkingSpot spot) {
        spot.removeVehicle();
        availableSpots++;
    }

    // Other methods for managing the parking lot
}

ParkingFloor

public class ParkingFloor {
    private int level;
    private List<ParkingSpot> spots;
    private int totalSpots;
    private int availableSpots;

    public ParkingFloor(int level, List<ParkingSpot> spots) {
        this.level = level;
        this.spots = spots;
        this.totalSpots = spots.size();
        this.availableSpots = calculateAvailableSpots();
    }

    public ParkingSpot findAvailableSpot(Vehicle vehicle) {
        for (ParkingSpot spot : spots) {
            if (!spot.isOccupied() && spot.getSize().equals(vehicle.getSize())) {
                spot.assignVehicle(vehicle);
                availableSpots--;
                return spot;
            }
        }
        return null; // No spot available
    }

    private int calculateAvailableSpots() {
        int count = 0;
        for (ParkingSpot spot : spots) {
            if (!spot.isOccupied()) count++;
        }
        return count;
    }

    public int getTotalSpots() {
        return totalSpots;
    }

    public int getAvailableSpots() {
        return availableSpots;
    }

    // Other methods related to managing the floor
}

Parking spot

public class ParkingSpot {
    private String spotId;
    private String size;
    private boolean isOccupied;
    private Vehicle vehicle;

    public ParkingSpot(String spotId, String size) {
        this.spotId = spotId;
        this.size = size;
        this.isOccupied = false;
        this.vehicle = null;
    }

    public void assignVehicle(Vehicle vehicle) {
        this.vehicle = vehicle;
        this.isOccupied = true;
    }

    public void removeVehicle() {
        this.vehicle = null;
        this.isOccupied = false;
    }

    public boolean isOccupied() {
        return isOccupied;
    }

    public String getSize() {
        return size;
    }

    // Other methods related to spot management
}

Vehicle

public abstract class Vehicle {
    protected String licensePlate;
    protected String size;

    public Vehicle(String licensePlate, String size) {
        this.licensePlate = licensePlate;
        this.size = size;
    }

    public String getLicensePlate() {
        return licensePlate;
    }

    public String getSize() {
        return size;
    }

    // Other vehicle-related methods
}

public class Car extends Vehicle {
    public Car(String licensePlate) {
        super(licensePlate, "Medium");
    }
}

public class Bike extends Vehicle {
    public Bike(String licensePlate) {
        super(licensePlate, "Small");
    }
}

public class Truck extends Vehicle {
    public Truck(String licensePlate) {
        super(licensePlate, "Large");
    }
}

Ticket

public class Ticket {
    private String ticketId;
    private Vehicle vehicle;
    private ParkingSpot spot;
    private Date entryTime;
    private Date exitTime;
    private double fee;

    public Ticket(String ticketId, Vehicle vehicle, ParkingSpot spot) {
        this.ticketId = ticketId;
        this.vehicle = vehicle;
        this.spot = spot;
        this.entryTime = new Date(); // Set entry time to current time
    }

    public void markExit() {
        this.exitTime = new Date(); // Set exit time to current time
        calculateFee();
    }

    private void calculateFee() {
        // Fee calculation logic, possibly using a strategy pattern
        long duration = exitTime.getTime() - entryTime.getTime(); // Duration in milliseconds
        this.fee = duration * 0.05; // Example fee calculation
    }

    public double getFee() {
        return fee;
    }

    // Other ticket-related methods
}

Payment

public class Payment {
    private String paymentId;
    private double amount;
    private Date paymentTime;
    private Ticket ticket;

    public Payment(String paymentId, double amount, Ticket ticket) {
        this.paymentId = paymentId;
        this.amount = amount;
        this.paymentTime = new Date(); // Set payment time to current time
        this.ticket = ticket;
    }

    public boolean processPayment() {
        // Payment processing logic
        return true; // Assuming payment is successful
    }

    // Other payment-related methods
}

Adhere to SOLID Guidelines

Single Responsibility Principle

Each class in our design has a single responsibility. For example, ParkingLot manages the overall parking lot, ParkingSpot manages an individual spot, and Ticket handles parking tickets. This clear separation ensures that changes in one aspect of the system don’t affect other parts.

Open/Closed Principle (OCP)

The use of inheritance allows for extending functionality without modifying existing classes. For instance, new vehicle types (e.g., ElectricCar) can be added by creating new subclasses of Vehicle without altering the existing Vehicle class. Similarly, new fee calculation strategies can be added by implementing new FeeStrategy classes.

Liskov Substitution Principle (LSP)

Subclasses like Car, Bike, and Truck can be used interchangeably with the Vehicle superclass. The system’s behavior remains consistent regardless of the specific vehicle type, adhering to LSP.

Interface Segregation Principle

Although we haven't explicitly defined interfaces, our design ensures that classes only contain methods relevant to their specific role. For example, Vehicle only includes methods related to vehicle characteristics, and ParkingSpot focuses on spot management.

Dependency Inversion Principle (DIP)

The use of strategies for fee calculation (e.g., FeeStrategy interface) allows high-level classes like Ticket to depend on abstractions rather than concrete implementations. This makes the system more flexible and easier to modify or extend.

Consider Scalability and Flexibility

Scalability

Horizontal Scaling (Adding More Floors and Spots): New floors can be added by simply instantiating additional ParkingFloor objects and adding them to the ParkingLot. Similarly, new spots can be added to any floor by adding ParkingSpot objects to the corresponding ParkingFloor.

Vertical Scaling (Handling More Vehicles and Larger Lots): Optimizations such as indexing spots by size or using efficient algorithms for searching available spots can be implemented to handle larger volumes of data as the system scales.

Database Scaling: Consider using a distributed database or sharding to handle the increased load. Data could be partitioned by floors or sections to ensure that no single database node becomes a bottleneck.

Flexibility

Adding New Vehicle Types: To add a new vehicle type, you would create a subclass of Vehicle and implement any specific logic required. The rest of the system will continue to function without modification.

Integrating New Payment Methods: New payment methods can be added by extending the Payment class or implementing a new fee strategy and associating it with a Ticket. This change does not require altering the core system.

Future Features (e.g., Automated Parking, Online Reservations): New features can be integrated by adding new classes or modules that interact with the existing ones. For example, an online reservation system might interact with the ParkingSpot and Ticket classes to reserve spots and issue tickets in advance.

Create/Explain your diagram(s)

Sequence Diagram

This sequence diagram shows the flow of events when a vehicle enters the parking lot, is assigned a spot, and receives a ticket:

Explanation:

The user requests a parking spot.
The ParkingLot checks with each ParkingFloor to find an available spot.
The available spot is assigned to the vehicle, and a Ticket is generated.
The Ticket is issued to the user.

Flow Diagram

This flow diagram outlines the high-level process of the parking lot system from entry to exit:

Explanation:

The vehicle arrives, and a spot is requested.
The ParkingLot finds and assigns an available spot, generating a ticket.
When the vehicle departs, the system calculates the fee, processes payment, and releases the spot.

Future improvements

To future-proof the parking lot system, consider integrating automated parking, real-time spot monitoring, and a mobile app for enhanced user convenience. Additionally, support for electric vehicles, dynamic pricing, and advanced security features will address evolving customer needs. Finally, scalability through distributed systems and smart city integration will ensure the system remains efficient and adaptable as it grows.