Requirements

Functional Requirements:

1. multiple parking floors
2. multiple size parking spots, supporting different types of vehicles for parking i.e 2 wheeler, cars, trucks etc.
3. each parking floor has multiple parking spots
4. ticket issuing on entry
5. fare charge on exit
6. fare estimation thorugh multiple strategies considering peak time, waiting time etc.
7. deny entry if parking lot is full

Non-Functional Requirements:

1. handle concurrency during entry
2. extensible to fare estimation strategies
3. extensible count of parking floors and parking spots

Core Objects & Relationships

1. Parking lot Manager, contains list of parking floors. It is composition relation as parking floor can't exist without parking lot
2. Parking floor contains list of parking spots. It is also composition relation as parking spots cant exist without parking floor
3. entry gate, issues ticket, it is association relation ticket can exist even without entry gate
4. exit gate also has ticket, for fare estimation, it is again association relation
5. ticket has properties: entry_time, vehicle_size<,vehicle_id,parking floor,parking spot
6. pricecalculationStrategyInterface class, which is inherited by concrete priceCalculation classes: pricebasedOnSize, pricebasedOnPeakTime
7. exitGate has pricecalculationStrategyInterface, for fare estimation, it is association relation
8. Vehicle class, vehicle id, vehicle size

APIs & Class Members

Deep Dive

SOLID Principle:

entry gate: checks for spot availability and issues ticket and assign spot

exit gate: release spot and fare estimation

priceCalculationStartegyInterface: fareestimation

ocp: priceCalculation strategy open to introducing new calculation strategies wityhout modifying existing ones

parking Spot Finder can also be made extensible my introducing interface in future to adhere to ocp

Liskov Substitution: derive price calculation strategies have all the propertiers of parent priceCalculationStrategyInterface

Interface Segmentation: derifed classes of priceCalculationStrategyInterface dont have to implement unncessaey functions

Dependency Inversion: instead of tight coupling and depending on concrete classes for price calculation, we pont to priceCalculationStrategyInterface

mutex locks help with concurrency, future enhancement: floor wise locks for independednt locking floor wise

availbaleSpotsCount help vaildatespot availability in O(1)

spot finding in 0(floorCount* spotCount*3)