Bird
Raised Fist0

Design a Meeting Scheduler - Rooms, Attendees, Conflicts, Recurring Events

LLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Class Trace
Step 1/4
Meeting and Scheduler composition

Scheduler composes multiple Meeting instances, owning their lifecycle strongly.

🎯 Tests understanding of composition in Java where Scheduler manages Meeting lifecycle and Meeting cannot exist independently.
public class Scheduler {
    private final List<Meeting> meetings = new ArrayList<>();
    public synchronized boolean addMeeting(Meeting m) {
        // atomic check and add to avoid conflicts
        if (conflicts(m)) return false;
        meetings.add(m);
        return true;
    }
}
Meeting as abstract class with shared state

Meeting is abstract because it holds shared state like attendees and title, which interfaces cannot hold in Java.

🎯 Tests why abstract class is chosen over interface due to instance fields and partial method implementations.
public abstract class Meeting {
    protected String id;
    protected String title;
    protected List<Attendee> attendees;
    public synchronized void schedule() {
        // scheduling logic
    }
    public void cancel() {
        // cancellation logic
    }
}
Notification realization and association

Notification is associated with Scheduler and realized as a concrete class to send messages.

🎯 Tests understanding of realization relationship and association lifecycle where Notification can exist independently.
public class Notification {
    private String message;
    public void send() {
        // send notification logic
    }
}
RecurrenceRule interface realization

RecurrenceRule defines a contract for recurrence logic, realized by concrete implementations for different rules.

🎯 Tests use of interface for OCP (Open-Closed Principle) allowing new recurrence rules without modifying existing code.
public interface RecurrenceRule {
    List<Date> applyRule(Meeting meeting);
}
public class WeeklyRecurrenceRule implements RecurrenceRule {
    public List<Date> applyRule(Meeting meeting) {
        // weekly recurrence logic
        return new ArrayList<>();
    }
}
📐
Class Diagram
Class Diagram
       +----------------+
       |  <<Abstract>>  |
       |    Meeting     |
       +----------------+
       | - id: String   |
       | - title: String|
       | - attendees:   |
       |   List<Attendee>|
       +----------------+
       | +schedule(): void [sync] |
       | +cancel(): void|
       +----------------+
              │
              │ composition
              │
       +----------------+
       |   Scheduler    |
       +----------------+
       | - meetings:    |
       |   List<Meeting>|
       +----------------+
       | +addMeeting(m: Meeting): boolean [sync] |
       | +notifyAll(): void |
       +----------------+
              │
              │ association
              │
       +----------------+
       |   Notification |
       +----------------+
       | - message:     |
       |   String       |
       +----------------+
       | +send(): void  |
       +----------------+
              │
              │ realization
              │
       +----------------+
       | RecurrenceRule |
       +----------------+
       | - ruleType:    |
       |   String       |
       +----------------+
       | +applyRule(): List<Date> |
       +----------------+
Design Rationale

This Meeting Scheduler design uses an abstract Meeting class to hold shared state like attendees and title, which interfaces cannot hold in Java, enforcing the use of abstract class for shared behavior and state. Scheduler composes Meeting instances, owning their lifecycle strongly, ensuring meetings cannot exist independently, demonstrating composition. Notification is associated with Scheduler and realized as a concrete class, showing association with independent lifecycle. RecurrenceRule is an interface realized by concrete classes to apply different recurrence patterns, following the Open-Closed Principle for extensibility. Synchronization on methods like addMeeting and schedule ensures thread-safe state changes, preventing race conditions in concurrent scheduling.

Primary Focus

✓ Abstract class vs Interface + Composition lifecycle + Realization + Synchronization

Practice

(1/5)
1. In designing the Vehicle abstraction for the Ride Booking system, should Vehicle be an abstract class or an interface, and why?
easy
A. Abstract class, because Vehicle has common state like licensePlate and shared methods like startEngine().
B. Interface, because Vehicle only defines behavior without any shared state or implementation.
C. Interface, because Java interfaces can now have default methods to share code and state.
D. Abstract class, because interfaces cannot enforce method signatures.

Solution

  1. Step 1: Analyze Vehicle's shared state and behavior

    Vehicle has common fields (e.g., licensePlate) and methods (e.g., startEngine) that require shared implementation and state storage.

  2. Step 2: Abstract class vs interface suitability

    Abstract classes allow shared state and method implementations, while interfaces cannot hold instance state. Thus, abstract class fits Vehicle better.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Shared state + behavior -> abstract class [check]
Hint: Shared state means abstract class, not interface [check]
Common Mistakes:
2. In a concurrent Job Scheduler, if the scheduleJob() method is not synchronized, which exact thread interleaving causes the same Job to be scheduled twice?
medium
A. Thread 1 and Thread 2 both call scheduleJob() simultaneously and both succeed without checks.
B. Thread 1 adds job, then Thread 2 removes it before completion, causing inconsistency.
C. Thread 1 checks if job exists -> false, context switch; Thread 2 checks -> false; both add job concurrently.
D. Thread 1 waits for Thread 2 to finish scheduling, causing deadlock.

Solution

  1. Step 1: Identify the check-then-act race condition

    Both threads check if the job is already scheduled before adding. Without synchronization, both see job absent.

  2. Step 2: Trace thread interleaving

    Thread 1 checks -> false, context switch before adding; Thread 2 checks -> false, adds job; Thread 1 resumes and adds job again, causing double scheduling.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Check-then-act gap without synchronization -> double scheduling [check]
Hint: Check-then-act gap -> double scheduling race [check]
Common Mistakes:
3. ElectricCar needs to be added to the product catalog with ChargingSpots. What is the minimum change to support this without modifying existing classes?
hard
A. Create a new ElectricCar class and a new ChargingSpot class, modifying Vehicle and Spot base classes to support them
B. Add ELECTRIC_CAR to VehicleType enum and CHARGING to SpotType enum, create ElectricCar extends Vehicle, update SpotCompatibility.COMPATIBILITY_MAP accordingly
C. Modify Vehicle class to add isElectric flag and add charging logic inside existing ParkingSpot classes
D. Add charging logic inside Vehicle class and extend SpotType enum with charging spots, modifying existing compatibility logic

Solution

  1. Step 1: Identify extensibility without modifying existing classes

    Adding new enum values and new classes for ElectricCar and ChargingSpot allows extension without changing existing class code, preserving OCP.

  2. Step 2: Why updating compatibility map is needed

    SpotCompatibility.COMPATIBILITY_MAP controls which vehicles fit which spots; updating it ensures ElectricCar and ChargingSpot compatibility without modifying base classes.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    New enums + classes + compatibility map update -> minimal existing class changes [check]
Hint: Add enums + classes + map, no base class changes [check]
Common Mistakes:
4. To support ElectricCar needing ChargingSpot in the file system's parking analogy, what is the minimum change to the current design to maintain extensibility without modifying existing classes?
hard
A. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally.
B. Modify Vehicle base class to include a boolean isElectric flag and add charging logic inside existing methods.
C. Create a new ElectricCar class and modify ParkingLot to handle charging spots explicitly.
D. Add a new ChargingSpot class inheriting from Spot and modify Vehicle to check for charging compatibility.

Solution

  1. Step 1: Identify extensibility requirements without modifying existing classes

    Adding new vehicle and spot types should not require changing existing class code to avoid violating OCP.

  2. Step 2: Use enums for types and external compatibility map to add new types and compatibility rules

    This allows adding ElectricCar and ChargingSpot by extending enums and maps without modifying existing classes.

  3. Step 3: Create ElectricCar subclass for specific behavior without altering Vehicle base class

    This maintains clean separation and extensibility.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Extend enums + external map + subclass -> minimal change [check]
Hint: Extend enums and maps, subclass new type, no existing class edits [check]
Common Mistakes:
5. You need to add support for ElectricCar and ChargingSpot in an existing parking system using Observer pattern. What is the minimum change to the current design to support this without modifying existing classes?
hard
A. Add a boolean isElectric flag to Vehicle and Spot classes and update existing logic to handle charging spots.
B. Modify Vehicle and Spot classes to include electric-specific fields and logic for charging compatibility.
C. Create a new ElectricCar class and ChargingSpot class, then modify the Subject to notify these new types explicitly.
D. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally.

Solution

  1. Step 1: Identify extensibility requirements

    Adding ElectricCar and ChargingSpot should not modify existing classes to respect OCP.

  2. Step 2: Evaluate options

    Modify Vehicle and Spot classes to include electric-specific fields and logic for charging compatibility. and D modify existing classes, violating OCP; Create a new ElectricCar class and ChargingSpot class, then modify the Subject to notify these new types explicitly. modifies Subject, increasing coupling.

  3. Step 3: Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally. adds new enum values and subclasses, updating compatibility externally, preserving existing class integrity.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    New enums and subclasses added externally -> existing classes unchanged [check]
Hint: Add enums and subclasses externally, keep existing classes untouched [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