This is our first blog in the series of Low Level Design. We'll start from designing and coding a Parking lot system. While coding we'll be following some design patterns that we discussed in earlier blogs, Part 1 and Part 2.
Before starting the design, one must know the Requirements and Objects of the system.
Requirements:-
- We have one entrance and one exit
- We have different parking spots for two, three and four wheelers
- Parking prices are based on hourly and minutes based
- There are multiple parking floors
- We have different strategies to find the parking spots like Parking Spot near to the elevator, Parking Spot near to entrance etc
Objects Required:-
- Ticket
- Entrance
- Parking Spot
- Vehicle, VehicleType (Enum)
Now, lets design 😎
But But But, Before coming to the design, there is one most important thing i.e. following either one of the approaches from
- Top Down Approach
- Bottom Up Approach
Here, In Top to Down approach we start from the system start. Here in our case our system starts from the entry of a vehicle into a Parking Space.
In Bottom to Up approach, we start from the main requirement (any) like we start from ParkingSpot and then further.
Thought Process:-
Now, here is our thought process while designing.
- Vehicle needs to be parked at some Spot (Design a Parking Spot)
- But we have different type of vehicles (2,3,4 wheelers) so make ParkingSpot as an interface and extend to TwoWheeler, ThreeWheeler and FourWheeler ParkingSpot.
- Now, we have ParkingSpots but to manage these ParkingSpots we have to make a Manager (ParkingSpotManager) which will be a centralized place to control the ParkingSpots.
- Here, we have a Parking Strategy (Strategy Pattern) that has different implementation.
- We have has-a relation which says it is not a child but it has an instance of that class
- Now, coming to Entrance and Ticket, we have entrance from where a person collects his ticket to park a vehicle. So, it should have a Ticket, Parking Spot Manager to find parking and all.
- Now, we have to include the Price on the ticket and price can be assigned from the entrance itself. Now, Price could be different and can have multiple implementations.
- Now, It might look a mess to you, But at the end combining all the stuff, it looks like this (Sorry, if image is not clear, kindly click on the Google Drive link for a High Quality Image)
We'll get to the code in our next blog, Follow for more updates
Top comments (9)
Very informative :)
Thanks 😎
If
Ticket
has-AVehicle
, then the member's type should beVehicle
, instead ofVehicleType
, no? or am I missing something?Yes You are right bro, Ticket should have Vehicle not VehicleType
I didn't reed till the very end, but for the ParkingSpot(first schema), wouldn't it be better to make it an Abstract Class, I guess the methos will have the same implementation for all extended classes, correct me if I'm wrong.
Great post!!
excellent post!
NOICE
Thanks Buddy