Bird
Raised Fist0

Restaurant Management System

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

MenuItem is an abstract class holding shared state like id, name, and price, which interfaces cannot hold in Java.

🎯 Tests whether candidate knows abstract class is correct over interface because MenuItem holds instance state (fields) that interfaces cannot have in Java.
public abstract class MenuItem {
    protected int id;
    protected String name;
    protected double price;
    public double getPrice() {
        return price;
    }
}
Order composition with MenuItem

Order composes multiple MenuItem objects, showing strong lifecycle ownership (composition).

🎯 Tests understanding of composition in Java where Order controls MenuItem lifecycle and uses synchronized addItem to prevent concurrent modification.
public class Order {
    private List<MenuItem> items = new ArrayList<>();
    public synchronized void addItem(MenuItem item) {
        items.add(item);
    }
}
Table composition with Order

Table composes an Order instance, indicating Table owns the Order lifecycle (composition).

🎯 Tests whether candidate distinguishes composition (Table owns Order) from association and understands lifecycle ownership in Java.
public class Table {
    private int tableNumber;
    private int capacity;
    private Order order = new Order();
    public boolean seatGuests(int n) {
        return n <= capacity;
    }
}
Kitchen association with Staff

Kitchen has an association with Staff, indicating Staff can exist independently of Kitchen.

🎯 Tests understanding of association in Java where Staff lifecycle is independent and Kitchen only references Staff.
public class Kitchen {
    private Staff staff;
    public void prepareOrder(Order order) {
        // preparation logic
    }
}
📐
Class Diagram
Class Diagram
       +----------------+
       |    <<Abstract>>|
       |     MenuItem   |
       +----------------+
       | - id: int      |
       | - name: String |
       | - price: double|
       +----------------+
       | + getPrice():  |
       |   double       |
       +----------------+
              ▲
              │
       +----------------+
       |   Order        |
       +----------------+
       | - id: int      |
       | - items: List< |
       |   MenuItem>    |
       +----------------+
       | + addItem(item:|
       |   MenuItem):   |
       |   void [sync]  |
       +----------------+
              │◆
              │ composition
       +----------------+
       |    Table       |
       +----------------+
       | - tableNumber: |
       |   int          |
       | - capacity: int|
       | - order: Order |
       +----------------+
       | + seatGuests(n:|
       |   int): boolean|
       +----------------+
              │
              │ association
       +----------------+
       |   Kitchen      |
       +----------------+
       | - staff: Staff |
       +----------------+
       | + prepareOrder(|
       |   order: Order)|
       +----------------+
Design Rationale

This class diagram illustrates key Java OOP design decisions in a Restaurant Management System. MenuItem is an abstract class because it holds shared state fields like id and price, which interfaces cannot hold in Java. Order composes MenuItem objects, enforcing strong lifecycle ownership and uses synchronized methods to ensure thread safety when modifying the item list. Table composes an Order, showing that Table owns the Order lifecycle, enforcing the composition relationship. Kitchen associates with Staff, reflecting that Staff can exist independently, demonstrating association. These design choices enforce SOLID principles, especially Single Responsibility and Open-Closed, while leveraging Java-specific constructs like synchronized methods and abstract classes for state management.

Primary Focus

✓ Composition vs Association lifecycle + Abstract class vs Interface + Strategy pattern realization

Practice

(1/5)
1. In the Elevator System design, the ElevatorController class uses a private constructor and a static synchronized getInstance() method to provide a single global access point. Which design pattern is applied here and why is it the correct choice?
easy
A. Factory pattern, because it creates ElevatorController instances on demand.
B. Singleton pattern, to ensure only one ElevatorController manages all elevators centrally.
C. Builder pattern, to incrementally construct ElevatorController with complex configuration.
D. Prototype pattern, to clone ElevatorController for each elevator instance.

Solution

  1. Step 1: Identify Singleton usage

    The private constructor and static synchronized getInstance() method restrict instantiation to one object, ensuring a single ElevatorController.

  2. Step 2: Why Singleton fits ElevatorController

    ElevatorController coordinates multiple elevators and floor queues centrally, so multiple instances would cause inconsistent state and scheduling conflicts.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Singleton ensures one global ElevatorController instance [check]
Hint: Singleton restricts to one instance for centralized control [check]
Common Mistakes:
2. In the LinkedIn OOP design, the ConnectionManager class uses a private constructor and a static synchronized getInstance() method to provide a single instance. Which design pattern is applied here, and why is this the correct choice for managing user connections?
easy
A. Factory pattern, because it creates different types of connections dynamically.
B. Singleton pattern, to ensure only one instance manages all user connections globally.
C. Builder pattern, to incrementally construct complex connection objects.
D. Prototype pattern, to clone existing connection instances for performance.

Solution

  1. Step 1: Identify the pattern from constructor and method signature

    The private constructor and static synchronized getInstance() method are classic signs of the Singleton pattern, ensuring a single instance.

  2. Step 2: Reason why Singleton fits connection management

    Managing user connections globally requires a single shared instance to avoid inconsistent states or duplicated connection managers.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Singleton ensures one global ConnectionManager instance [check]
Hint: Private constructor + static getInstance() -> Singleton [check]
Common Mistakes:
3. In designing a collection class that supports iteration, should the iterator interface be an abstract class or an interface in Java, and why?
easy
A. Interface, because it enforces immutability of the collection during iteration.
B. Abstract class, because it allows sharing state and default implementation for iteration methods.
C. Abstract class, because Java interfaces cannot have methods with parameters.
D. Interface, because it defines behavior without state, allowing multiple implementations and better flexibility.

Solution

  1. Step 1: Understand Java interface vs abstract class

    Interfaces define behavior contracts without state, allowing multiple implementations. Abstract classes can hold state but restrict multiple inheritance.

  2. Step 2: Apply to iterator design

    Iterator interface defines traversal methods (e.g., hasNext(), next()) without state, enabling different iterator implementations per collection type.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Iterator as interface enables flexible, stateless traversal contracts [check]
Hint: Iterator interface defines behavior, no state needed [check]
Common Mistakes:
4. You want to add a WeekendFeeStrategy to the rate limiter's fee calculation without modifying existing classes. Which SOLID principle applies and what is the minimum change?
medium
A. Add weekend flag to RateLimiter and use if-else inside existing fee method
B. Create new WeekendFeeStrategy implementing FeeStrategy interface; inject it via constructor (OCP and DIP enforced)
C. Modify RateLimiter class to add weekend fee logic directly, violating OCP
D. Create WeekendFeeStrategy but modify existing FeeStrategy implementations to handle weekend

Solution

  1. Step 1: Identify SOLID principle for adding new fee logic

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

  2. Step 2: Evaluate options for minimal change respecting OCP and DIP

    Add weekend flag to RateLimiter and use if-else inside existing fee method adds weekend flag and if-else inside existing method, violating OCP by modifying existing class. Create new WeekendFeeStrategy implementing FeeStrategy interface; inject it via constructor (OCP and DIP enforced) respects OCP and DIP by adding new class and injecting it.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Minimal change but violates OCP by modifying existing class [check]
Hint: OCP: add new class, not modify existing code [check]
Common Mistakes:
5. You need to add support for ElectricCar and ChargingSpot in the existing parking system using the command pattern. What is the minimum change to the current design to support this without modifying existing classes?
hard
A. Create a new ElectricCarCommand class that extends existing commands and override methods to handle charging spots
B. Modify Vehicle class to add isElectric flag and add logic in existing commands to handle charging spots
C. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar extends Vehicle, and update SpotCompatibility.COMPATIBILITY_MAP accordingly
D. Add charging logic inside existing ParkingLot class and modify commands to check for electric cars

Solution

  1. Step 1: Identify extensibility requirements

    Adding new vehicle and spot types without modifying existing classes enforces OCP and avoids class explosion.

  2. Step 2: Evaluate options for minimal invasive change

    Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar extends Vehicle, and update SpotCompatibility.COMPATIBILITY_MAP accordingly adds new enum values and new class, updating compatibility map without changing existing classes. Options B, C, D modify existing classes or add complex logic violating OCP.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New enums and class added, existing classes unchanged [check]
Hint: Add enums and classes, avoid modifying existing code [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