Bird
Raised Fist0

Parking Lot System

LLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Class Trace
Step 1/4
Vehicle abstract class

Vehicle is an abstract class holding shared state like licensePlate and vehicleType which interfaces cannot hold in Java.

🎯 Tests whether candidate knows abstract class is correct because Vehicle has instance fields that interfaces cannot have in Java.
public abstract class Vehicle {
    private String licensePlate;
    private String vehicleType;
    public String getLicensePlate() { return licensePlate; }
    public String getVehicleType() { return vehicleType; }
}
ParkingLot composition

ParkingLot composes ParkingSpot objects and holds a PricingStrategy reference, showing composition lifecycle ownership of spots.

🎯 Tests understanding of composition where ParkingLot owns ParkingSpots lifecycle and PricingStrategy is associated for OCP.
public class ParkingLot {
    private List<ParkingSpot> spots;
    private PricingStrategy pricingStrategy;
    public synchronized boolean parkVehicle(Vehicle v) {
        // park logic
    }
}
PricingStrategy interface

PricingStrategy is an interface defining calculateFee(), enabling open-closed principle for pricing algorithms.

🎯 Tests if candidate understands interface use for behavior abstraction without state, enabling multiple pricing implementations.
public interface PricingStrategy {
    double calculateFee(ParkingSpot spot, long duration);
}
FlatRatePricingStrategy realization

FlatRatePricingStrategy implements PricingStrategy interface providing a concrete flat rate fee calculation.

🎯 Tests realization relationship and how concrete classes implement interfaces to extend behavior without modifying existing code.
public class FlatRatePricingStrategy implements PricingStrategy {
    private double flatRate;
    public double calculateFee(ParkingSpot spot, long duration) {
        return flatRate;
    }
}
📐
Class Diagram
Class Diagram
       +----------------+
       | <<Abstract>>   |
       |   Vehicle      |
       +----------------+
       | - licensePlate |
       | - vehicleType  |
       +----------------+
       | + getLicense() |
       | + getType()    |
       +----------------+
              │ extends
       +----------------+
       |  ParkingLot    |
       +----------------+
       | - spots: List  |
       | - pricing:     |
       |   PricingStrat |
       +----------------+
       | + parkVehicle  |
       | + unparkVehicle|
       +----------------+
              ◆ composition
       +----------------------+
       | <<Interface>>        |
       | PricingStrategy      |
       +----------------------+
       | + calculateFee()     |
       +----------------------+
              ─ ─ ─► realization
       +--------------------------+
       | FlatRatePricingStrategy  |
       +--------------------------+
       | - flatRate: double       |
       +--------------------------+
       | + calculateFee()         |
       +--------------------------+
Design Rationale

This diagram illustrates key Java OOP design decisions for a Parking Lot System. Vehicle is an abstract class because it holds state like licensePlate and vehicleType, which interfaces cannot hold in Java. ParkingLot composes ParkingSpot objects, enforcing lifecycle ownership via composition, and holds a PricingStrategy reference to apply the open-closed principle by delegating pricing behavior. PricingStrategy is an interface defining calculateFee(), enabling multiple pricing algorithms without modifying ParkingLot. FlatRatePricingStrategy realizes PricingStrategy, showing how concrete classes implement interfaces to extend behavior. These decisions demonstrate Java-specific use of abstract classes for shared state, composition for lifecycle management, and interfaces for behavior abstraction and extensibility.

Primary Focus

✓ Abstract class vs Interface state + Composition lifecycle + Strategy pattern OCP + Realization

Practice

(1/5)
1. In the ESPNcricinfo system, the Match class has a private constructor and a static synchronized getInstance() method to ensure only one instance per match ID exists. Which design pattern is applied here and why is this the correct use case?
easy
A. Singleton Pattern, because it ensures a single instance per match ID with thread safety.
B. Factory Pattern, because it creates objects based on input parameters.
C. Builder Pattern, because it separates construction and representation of Match objects.
D. Prototype Pattern, because it clones existing Match instances to avoid new creation.

Solution

  1. Step 1: Identify the pattern from constructor and getInstance()

    The private constructor prevents direct instantiation, and the static synchronized getInstance() ensures controlled, thread-safe instance creation.

  2. Step 2: Why Singleton fits this use case

    Singleton ensures only one Match instance per match ID exists, avoiding inconsistent state across threads.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Private constructor + synchronized getInstance() -> Singleton pattern [check]
Hint: Private constructor + synchronized getInstance() -> Singleton [check]
Common Mistakes:
2. The ESPNcricinfo system wants to add a WeekendFeeStrategy for premium commentary access pricing. Given the current design where FeeStrategy is an interface implemented by pricing classes, what is the minimum change required to add this feature following SOLID principles?
medium
A. Modify the existing StandardFeeStrategy class to add weekend pricing logic.
B. Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it where needed.
C. Add weekend pricing logic directly inside the CommentaryService class.
D. Add a boolean flag isWeekend in FeeStrategy interface and handle logic in all implementations.

Solution

  1. Step 1: Identify SOLID principle involved

    Open-Closed Principle (OCP) requires adding new behavior without modifying existing classes.

  2. Step 2: Evaluate options for OCP compliance

    Adding a flag in the interface forces all implementations to change, violating OCP; creating a new class preserves OCP.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    New class implementing FeeStrategy -> OCP respected [check]
Hint: New behavior -> new class implementing interface -> OCP [check]
Common Mistakes:
3. You want to add a WeekendFeeStrategy to calculate parking fees differently on weekends using the current Iterator-based design. Which minimal change respects the Open-Closed Principle (OCP)?
medium
A. Add a boolean flag isWeekend to the FeeStrategy interface and implement conditional logic in all subclasses.
B. Modify the existing FeeStrategy class to add weekend logic with an if-else condition.
C. Create a new WeekendFeeStrategy class implementing FeeStrategy and update the client code to use it when appropriate.
D. Combine all fee strategies into a single class with multiple methods and switch logic inside the iterator.

Solution

  1. Step 1: Understand OCP requirements

    OCP requires software entities to be open for extension but closed for modification.

  2. Step 2: Evaluate options

    Modify the existing FeeStrategy class to add weekend logic with an if-else condition. modifies existing class, violating OCP. Create a new WeekendFeeStrategy class implementing FeeStrategy and update the client code to use it when appropriate. adds a new class but requires client code modification, which may violate DIP. Add a boolean flag isWeekend to the FeeStrategy interface and implement conditional logic in all subclasses. extends interface with a flag, allowing existing implementations to adapt without changing their core logic. Combine all fee strategies into a single class with multiple methods and switch logic inside the iterator. centralizes logic, violating SRP and OCP.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Extending interface with flag allows extension without modifying existing classes [check]
Hint: OCP: extend behavior without modifying existing classes [check]
Common Mistakes:
4. To support ElectricCar orders requiring ChargingSpots in the existing Order Management System, what is the minimum change that respects extensibility without modifying existing classes?
hard
A. Modify VehicleType enum to include ElectricCar and add charging logic inside existing Vehicle class.
B. Create a new ElectricCar class and modify Order class to handle charging spots explicitly.
C. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally.
D. Add charging spot logic inside existing Spot class and modify OrderState to handle ElectricCar states.

Solution

  1. Step 1: Identify extensibility requirements

    New vehicle and spot types must be added without modifying existing classes to respect OCP.

  2. Step 2: Evaluate options

    Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally. adds new enum values and classes externally, updating compatibility map without changing existing code; Options B, C, D modify existing classes violating OCP.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Adding new enums and classes externally respects OCP [check]
Hint: Add new enums and classes externally, no existing class changes [check]
Common Mistakes:
5. To add support for ElectricCar needing ChargingSpot in the current parking lot design, what is the minimum change that respects extensibility and avoids modifying existing classes?
hard
A. Modify Vehicle base class to include charging logic and add ChargingSpot as a subclass of ParkingSpot.
B. Add charging logic inside ParkingLot class and create a new ChargingSpot type without changing enums.
C. Create a new ElectricVehicle interface and modify existing classes to implement it.
D. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility.COMPATIBILITY_MAP accordingly.

Solution

  1. Step 1: Identify extensibility without modifying existing classes

    Enums are extended with new constants; new subclass ElectricCar is created without changing existing classes.

  2. Step 2: Update compatibility map to include new vehicle and spot types

    SpotCompatibility.COMPATIBILITY_MAP is updated to reflect which spots fit ElectricCar, preserving OCP.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Extend enums + new subclass + update compatibility map -> no existing class modified [check]
Hint: Extend enums + new subclass + update map -> no existing class changed [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard