LLD-4 Parking Lot

In this article, we will discuss low-level design for a parking lot.

Parking Lot

Requirements Clarification:

1. A parking lot is an open-space building
2. It might have some number of floors.
3. Each floor has several spots.
4. Each floor has many entry/ exit points.
5. A spot can either be occupied or free.
6. The spots are divided into 3 types
   - a spot for heavy-weight vehicles
   - a spot for medium-weight vehicles
   - a spot for light-weight vehicles
7. A parking lot will charge some amount for the duration the vehicle is parked.
8. The base charge will be different for each type of vehicle. There might be different strategies to calculate the charge.
   - heavy weight:100 base charge up to 1 hr, then 100 extra for every hr
   - medium weight: 50 base charge up to 1 hr, then 80 extra for every hr
   - light-weight: 30 base charge up to 1 hr, then 50 extra for every hr
9. A ticket/ receipt will be generated for each vehicle parked
10. Payment should be done at the exit of the vehicle
11. Only that many vehicles can be parked until we have free slots.
12. Customers can pay via both cards and cards.
13. Bill Receipt will generated at the exit point.
14. There can be different strategies to get free/ available slots

Additional use cases

1. There can be vehicle types like diesel/petrol, electric, bikes
2. The Spots might have charged for electric vehicles
3. An additional charge will be there charging
4. A charging facility might be provided by an operator
5. Operator details need to be stored

Functionalities Implemented

1. Generate Ticket On Entry
2. Generate Bill on Exit

Find Entities (Class Diagram)

The next step is to convert those requirements into design diagrams to get a better understanding of the system we are going to develop. A UML or Class diagram is a way of visualizing a software program using a collection of diagrams.

• Top-down approach — The major focus is on breaking the bigger problem into smaller ones and then repeating the process with each problem.

HLD Architecture and Sequence Diagram

• Bottom-up approach — Primarily focuses on identifying and resolving the smallest problems and then integrating them to solve the bigger problem. The best thing to move in a bottom-up approach is to draw a class diagram.

1. Parking Spot:
   - Has status — available/ occupied/ not available
   - Has floor, on which floor of the parking lot this spot is.
   - Has spot type — which type of vehicle should be parked on the spot.

Parking Spot

Note: A spot may have a vehicle also. What I have considered is to include Vehicle and Spot in separate Ticket Class. From there only, we get to know, at which spot of which floor, which vehicle is placed.

2. Parking Floor:
- Has Parking spots
- Has Floor number

Parking Floor

3. Parking Lot:
- Has Parking Floors
- Has Entry/ Exit gates
- Has Parking Lot Status
- Name, Address, etc.

Parking Lot

4. Vehicle:
- Vehicle Number
- Vehicle Type

Vehicle

5. Ticket: to be generated at entry time.
- has spot details.
- has vehicle details.
- has gate details.
- has entry time.

Ticket

6. Gate:
- Gate Type (Entry/Exit)

7. Bill:
- has ticket details (involves spot and vehicle details)
- has payment details.
- has gate details.
- has exit time.

Bill

Now, When a vehicle comes to the parking lot, we need to assign a spot to the vehicle. There can be multiple ways to assign a spot (which means there can be different strategies whose main task is to assign a spot). Thus SpotAssignmentStrategy can be an interface.

8. Spot Assignment Strategy:

Spot Assignment Strategy

Similarly, we can have different ways to calculate the amount for the time the vehicle is parked.

Thus the overall architecture is:

Complete Class Diagram

Directory Structure to follow:

Directory Structure

1. Entities: All the classes are to be declared in this package.
2. Controllers: All the functionalities that the main class will perform should be written in controllers. A Controller is responsible for performing all the specific functions related to a class. The Main Class should not directly deal with classes. Controllers take Request DTOs as input and share response DTO as response.
3. Services: All the controllers should have an attribute to the respective service class. Service is responsible for performing low-level implementation for a functionality and mainly deals with entities.
4. DTOs: DTOs are request-response structures for a particular functionality.
5. Repositories: Repos mainly deal with database-related activities. All the query execution is done in the repository package.
6. Exceptions: Exceptions/ Error package mainly deals with error definition. Any error to be sent in response or logged should be defined in the exceptions package.

These are the main packages that can be included in any of the projects. We can define any number of packages as per our need to have readable and maintainable code.

Refer to the code 👀:

Code Repo: https://github.com/Akhilesh53/Design/tree/main/ParkingLot

Let’s connect on LinkedIn.💁