Loading...
Based on the requirements and use cases, identify the main objects of the system and analyze how they interact and relate to each other...
class User{
id,
name,
email id,
phoneNo,
List
}
Abstract class Vehicle{
id,
licensePlate,
vehicleName,
vehicleType,
userId,
}
class MotorCycle extend vehicle{
}
class car extend vehicle{
}
class Truck extend vehicle{
}
user and vehicle will relate to each other with userId
one user can have multiple vehicle.
Abstract class ParkingSpot{
spotId,
isAvailable,
parkingType,
parkingStartTime,
parkingEndTime,
Vehicle vehicle,
}
class HandicappedSpot extends ParkingSpot{
}
class CompactSpot extends ParkingSpot{
}
class LargeSpot extends ParkingSpot{
}
A parking spot has a reference to the vehicle currently occupying it.
ParkingFloor{
Map
findAvailableSpot(vehicleType type);
}
ParkingLot(SingleTone){
ParkingFloor;
public ParkingTicket parkVehicle(Vehicle vehicle);
public Amount unparkVehicle(Vehicle vehicle);
}
ParkingTicket{
ParkingSpot parkingSpot;
}
Tranaction{
id,
transactionId,
amount,
transactionType,
ParkingTicket ticket;
}
parking and transaction table will relate to each other through with parkingID.
For each class, define the attributes (data) it will hold and the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation. Write your code in the code editor below.
Explain design tradeoffs you considered. Check and explain whether your design adheres to SOLID principles. Explain how your design can handle changes in scale and whether it would be easy to extend with new functionalities. Identify areas for future improvement...
Your design demonstrates several key SOLID concepts:
ParkingSpot) from the session data (ParkingTicket) and the financial record (Transaction).Vehicle class, the system is open for extension (e.g., adding ElectricCar or Ambulance) but closed for modification of the core parkVehicle logic.PricingStrategy interface allows you to swap out HourlyPricing for FlatRatePricing without touching the ParkingTicket class.In a high-traffic lot, two cars might try to grab the same "last spot" at the same microsecond.
synchronized block in the Singleton accessor and would implement a ReentrantLock at the ParkingFloor level when searching for spots.ParkingFloor objects to the ParkingLot list dynamically.ParkingLot Singleton into a microservice where spot availability is tracked in a distributed cache like Redis to ensure low-latency lookups across different gates.ParkingFloor manage its own spots (Centralized). The alternative was letting ParkingSpot objects broadcast their own status. I chose the former to simplify the "find available spot" search, reducing the time complexity to $O(F \times S)$ where $F$ is floors and $S$ is spots per floor.PriorityQueue to manage a waiting list based on vehicle arrival time.ElectricSpot that monitors KWh usage and adds it to the final Transaction.