Requirements
Determine the different ways the system will be used. This includes main functions the system needs to perform and who will use it.
- Manage vehicle parking across multiple levels.
- Parking spot assignment based on vehicle size.
- Parking spot availability checking for a given vehicle size.
- Fee calculation based on parking duration.
Use cases by actor wise
Customer/Vehicle (Parking Vehicle)
- Vehicle comes to parking lot
- Check if a parking spot is available for its vehicle size.
- If spot not available, leaves the parking lot
- Generate Parking ticket and park.
- Vehicle pays for the ticket (based on duration)
- Vehicle Vacate parking spot
Parking Lot admin (Manages)
- Parking lot admin can add/remove/update parking level in parking lot
- Parking lot admin can add/remove/update parking spot in parking level
Parking lot system
- Generate ticket for customer by assigning a parking spot
- Collects payment from customer by checking duration of ticket
- Un assign parking spot after customer vacate
Define Core Objects
Based on the requirements and use cases, identify the main objects of the system...
- User (Abstract class)
- Admin (extends User)
- ParkingLotService [to support parking lot system related use cases]
- Address
- ParkingTicket
- ParkingLot
- Vehicle
- ParkingLevel
- ParkingSpot
- CompactParkingSpot
- MedimParkingSpot
- LargeParkingSpot
- VehicleSize Enum
- PaymentService [To be used in ParkingLotService when customer is vacating the spot]
- PaymentInfo
Note: We don't need Customer Object because, Vehicle is the one interacting with our system.
Analyze Relationships
Determine how these objects will interact with each other to fulfill the use cases...
- ParkingLot is main object. It is composed of 0 to many ParkingLevel objects
- ParkingLot has Address
- ParkingLevel is composed of 0 to many ParkingSpot objects
- ParkingLevel contains level id
- ParkingLotSevice generates ParkingTicket (Association)
- ParkingLotService asks PaymentService to collect Payment
- PaymentService generates PaymentInfo
- ParkingTicket contains Vehicle, ParkingSpot
- Vehicle contains VehicleSize Enum
- ParkingSpot contains parked Vehicle
- PaymentInfo contains ParkingTicket for which the payment is created.
Establish Hierarchy
Design inheritance trees where applicable to promote code reuse and polymorphism. This step involves identifying common attributes and behaviors that can be abstracted into parent classes...
User is an abstract class, Admin extends it.
We can add Address, name, email in User class. This will help to add any new user types like ParkingAttendent in future.
ParkingSpot is an abstract class which defines fee per hour generally. And we have CompactParkingSpot, MediumParkingSpot, LargeParkingSpot can extend ParkingSpot and override the fee per hour accordingly.
Design Patterns
Consider using design patterns (e.g., Factory, Singleton, Observer, Strategy) that fit the problem...
We can use Strategy design pattern to assign parking spot to a vehicle
We can use Strategy design pattern to calculate parking fee.
- We might be calculating fee for duration currently but in future we may calculate fee for duration and vehicle size also.
Define Class Members (write code)
Attributes: For each class, define the attributes (data) it will hold...
Methods: Define the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation.
public class Address {
private String addressLane1;
private String addressLane2;
private String city;
private String state;
private String country;
private String zipCode;
//Constructor
//getter and setters
}
public abstract class User {
private String name;
private String email;
private String password;
private Address address;
//constructor to set above properties from child classes
//getter and setters for private properties.
}
public class Admin extends User {
private ParkingLotService parkingLotService;
//Constructor
public void addParkingLevel(ParkingLevel parkingLevel) {
//Delegates to ParkingLotService
parkingLotService.addParkingLevel(parkingLevel);
}
public void updateParkingLevel(ParkingLevel parkingLevel) {
//Delegates to ParkingLotService
parkingLotService.updateParkingLevel(parkingLevel);
}
public void removeParkingLevel(ParkingLevel parkingLevel) {
//Delegates to ParkingLotService
parkingLotService.removeParkingLevel(parkingLevel);
}
}
public enum VehicleSize {
COMPACT, MEDIUM, LARGE;
}
public class Vehicle {
private String regId;
private VehicleSize vehicleSize;
}
public abstract class ParkingSpot {
private int feePerHour;
private boolen isOccupied;
}
pubilc class CompactParkingSpot extends ParkingSpot {
//can override feePerHour if needed
}
pubilc class MediumParkingSpot extends ParkingSpot {
//can override feePerHour if needed
}
pubilc class LargeParkingSpot extends ParkingSpot {
//can override feePerHour if needed
}
pubilc class ParkingLevel {
private int floorNumber;
private List<ParkingSpot> parkingSpots;
public void addParkingSpot(ParkingSpot parkingSpot) {
this.parkingSpots.add(parkingSpot);
}
//Similarly for update and edit parkingSpot ;
}
public class ParkingLot {
private Long Id;
private Address Address;
private List<ParkingLevel> parkingLevels;
//Keeping ParkingLot separated from parking lot operations at is is responsibile for managing its state only as a core entity/object.
public void addParkingLevel(ParkingLevel parkingLevel) {
this.parkingLevels.add(parkingLevel);
}
//Similarly for update and edit parkingLevel;
}
public class ParkingTicket {
private LocalDateTime generatedAt;
private ParkingSpot parkingSpot;
private Vehicle vehicle;
public double getParkingFee() {
return 0.0; //Return fee by consulting ParkingSpot feePerDuration;
}
}
public class PaymentInfo {
private String paymentId;
private ParkingTicket parkingTicket;
}
public class PaymentService {
public PaymentInfo processPayment(ParkingTicket parkingTicket) {
//Assuming only one type of payment exists for now.
}
}
public class ParkingLotService {
private ParkingLot parkingLot;//Taking a reference for now, but to hanlde multiple parkinglots in future, we can take parking lot id as a reference to all the service methods.
private PaymentService paymentService;
public void addParkingLevel(ParkingLevel parkingLevel) {
//Delegates to ParkingLot
parkingLot.addParkingLevel(parkingLevel);
}
public void updateParkingLevel(ParkingLevel parkingLevel) {
//Delegates to ParkingLot
parkingLot.updateParkingLevel(parkingLevel);
}
public void removeParkingLevel(ParkingLevel parkingLevel) {
//Delegates to ParkingLot
parkingLot.removeParkingLevel(parkingLevel);
}
public boolean isSpotAvailable(Vehicle vehicle) {
return true;
}
public ParkingTicket occupyParkingSpot(Vehicle vehicle) {
return null; //It returns ParkingTicket.
}
public PaymentInfo vacateParkingSpot(ParkingTicket parkingTicket) {
return null; //It will return PaymentInfo
}
}
Adhere to SOLID Guidelines
Check and explain whether your design adheres to solid principles (Ask interviewer what SOLID principle is if you can not recall it.)...
Consider Scalability and Flexibility
Explain how your design can handle changes in scale and whether it would be easily to extend with new functionalities...
Create/Explain your diagram(s)
Try creating a class, flow, state and/or sequence diagram using the diagramming tool. Mermaid flow diagrams can be used to represent system use cases. You can ask the interviewer bot to create a starter diagram if unfamiliar with the tool. Briefly explain your diagrams if necessary...
Future improvements
Critically examine your design for any flaws or areas for future improvement...