Requirements

Determine the different ways the system will be used. This includes main functions the system needs to perform and who will use it.

Function:

  1. manage parking across multiple floors
  2. spot assignment based on vehicle size
  3. spot availability checking
  4. fee calculation based on duration



Define Core Objects

Based on the requirements and use cases, identify the main objects of the system...

  1. ParkingLot:
    1. val availableSpots: Map<Size, List<ParkingSpot>>
    2. val occupiedSpots: Map<String, ParkingSpot>
    3. fun assignSpot(car: Car)
    4. fun checkOut(car: Car)
  2. ParkingSpot:
    1. val id: Int
    2. val floor: Int
    3. var lastParkingTimestamp: Int
    4. var parkedCarLicense: String
  3. Car:
    1. val license: String
    2. val size: Enum Size
  4. FeeCalculator:
    1. fun calculate(size: Enum, durationMinutes: Int)



Analyze Relationships

Determine how these objects will interact with each other to fulfill the use cases...


  1. Assigning a spot for a new car (ParkingLot.assignSpot(car: Car)):
    1. based on car.size, check corresponding availableSpots[car.size]
    2. if there is a spot available, pick a random spot and assign it to the car by setting ParkingSpot.parkedCarLicense = car.license and ParkingSpot.lastParkingTimestamp = now. Move the spot from availableSpots to occupiedSpots
    3. if there is no same size spot available, check larger size spots and do the same
    4. Otherwise, return no spot available to client
  2. A car checks out (ParkingLot.checkOut(car: Car)):
    1. get the car's parked lot by occupiedSpots[car.license]
    2. calculate the duration, use FeeCalculator.calculate with the parked lot's size and computed duration, charge customer the fee
    3. remove occupiedSpots[car.license] and put the parked lot back into the availableSpots



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...

Potentially, FeeCalculator can have subclasses for different fee calculation policies.




Design Patterns

Consider using design patterns (e.g., Factory, Singleton, Observer, Strategy) that fit the problem...

ParkingLot and FeeCalculator will be Singleton. ParkingSpot will be composed into ParkingLot .


Additionally, if we have different fee calculation policies, FeeCalculator can be implemented with a strategy pattern, with different subclasses implement different fee calculation logic based on size and duration.


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.


object ParkingLot(val availableSpots: Map<Size, List<ParkingSpot>>, val occupiedSpots: Map<String, ParkingSpot>){ fun assignSpot(car: Car): Boolean fun checkOutAndPay(car: Car): Double } interface ParkingSpot(val id: Int, val floor: Int, var lastParkingTimestamp: Int, var parkedCarLicense: String) interface Car(val license: String, val size: Enum Size) enum class Size { SMALL, MEDIUM, LARGE } object FeeCalculator{ fun calculate(size: Size, durationMinutes: Int) }






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.)...


  1. Single responsibility: each class is for one single purpose
  2. Open-close: ParkingSpot and Car are closed for modification, open to extension
  3. Dependancy inversion: ParkingLot is the higher-level object, ParkingSpot, Car and FeeCalculator can all be interface which lower level classes implement each



Consider Scalability and Flexibility

Explain how your design can handle changes in scale and whether it would be easily to extend with new functionalities...

ParkingSpot, Car and FeeCalculator can all be interfaces, and we can implement those interfaces to offer new type of ParkingSpot, Car and FeeCalculator.




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...

New funtionality:

  1. Let user choose floor preference
  2. Show user availability
  3. Fee calculation based on availabilities.