Bird
Raised Fist0

Why LLD Exists and What HLD Cannot Tell You

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

DesignDecision is an abstract class holding shared state like description and rationale, which interfaces in Java cannot hold because they cannot have instance fields.

🎯 Tests whether candidate knows abstract class is chosen over interface because it holds state fields description and rationale, which interfaces cannot hold in Java.
public abstract class DesignDecision {
    private String description;
    private String rationale;
    public String getDescription() { return description; }
    public String getRationale() { return rationale; }
}
Composition between Entity and LifecycleOwnership

Entity composes LifecycleOwnership, meaning LifecycleOwnership cannot exist independently and is tightly coupled to Entity's lifecycle.

🎯 Tests whether candidate distinguishes composition (strong lifecycle ownership) from association, understanding that LifecycleOwnership is created and destroyed with Entity.
public class Entity {
    private String name;
    private final LifecycleOwnership lifecycleOwnership;
    public Entity(String name, LifecycleOwnership lifecycleOwnership) {
        this.name = name;
        this.lifecycleOwnership = lifecycleOwnership;
    }
    public String getName() { return name; }
    public LifecycleOwnership getLifecycleOwnership() { return lifecycleOwnership; }
}
Association between Entity and MethodSignature

Entity has an association to MethodSignature, indicating MethodSignature can exist independently and is not lifecycle-bound to Entity.

🎯 Tests whether candidate understands association means MethodSignature has independent lifecycle and can be shared or reused beyond Entity.
public class Entity {
    private MethodSignature methodSignature;
    public void setMethodSignature(MethodSignature ms) {
        this.methodSignature = ms;
    }
    public MethodSignature getMethodSignature() { return methodSignature; }
}
Template Method pattern realization

TemplateMethod is an interface realized by concrete classes to enforce a fixed algorithm skeleton with synchronized executeTemplate method to ensure thread-safe execution.

🎯 Tests whether candidate knows synchronized keyword on executeTemplate method ensures atomicity and visibility in concurrent Java environments, critical for Template Method pattern correctness.
public interface TemplateMethod {
    public synchronized void executeTemplate();
}
📐
Class Diagram
Class Diagram
       +----------------------+
       | <<Abstract>>         |
       | DesignDecision       |
       |----------------------|
       | -description: String |
       | -rationale: String   |
       |----------------------|
       | +getDescription():   |
       |   String             |
       | +getRationale():     |
       |   String             |
       +----------------------+
               │ extends
       +----------------------+
       | Entity               |
       |----------------------|
       | -name: String        |
       |----------------------|
       | +getName(): String   |
       +----------------------+
               ◆ composition
       +----------------------+
       | LifecycleOwnership   |
       |----------------------|
       | -owner: String       |
       | -type: String        |
       |----------------------|
       | +getOwner(): String  |
       | +getType(): String   |
       +----------------------+
               ──► association
       +----------------------+
       | MethodSignature      |
       |----------------------|
       | -signature: String   |
       |----------------------|
       | +getSignature():     |
       |   String             |
       +----------------------+
               ─ ─ ─► realization
       +----------------------+
       | TemplateMethod       |
       |----------------------|
       | +executeTemplate():  |
       |   void [sync]        |
       +----------------------+
Design Rationale

This diagram illustrates four key Java OOP design decisions. First, DesignDecision is an abstract class because it holds shared instance state fields description and rationale, which interfaces cannot hold in Java. Second, Entity composes LifecycleOwnership, enforcing strong lifecycle ownership per composition semantics. Third, Entity associates with MethodSignature, showing MethodSignature's independent lifecycle. Finally, TemplateMethod is realized as an interface with a synchronized executeTemplate method, demonstrating Java concurrency control to ensure thread-safe template execution. These decisions enforce SOLID principles and clarify lifecycle ownership and concurrency in Java low-level design.

Primary Focus

✓ Abstract class state vs interface behavior + Composition lifecycle + Template Method pattern realization

Practice

(1/5)
1. In a Java system, you have a class LegacyRectangleAdapter that implements the Shape interface by internally using a LegacyRectangle class with incompatible methods. Which design pattern is applied here and why is it the correct choice?
easy
A. Decorator pattern, because it adds new behavior to LegacyRectangle without changing its interface.
B. Adapter pattern, because it converts LegacyRectangle's interface to the Shape interface expected by clients.
C. Facade pattern, because it simplifies the interface of LegacyRectangle for easier use.
D. Proxy pattern, because it controls access to LegacyRectangle and adds caching.

Solution

  1. Step 1: Identify the role of LegacyRectangleAdapter

    The adapter wraps LegacyRectangle to provide the Shape interface expected by clients, enabling incompatible interfaces to work together.

  2. Step 2: Differentiate from other patterns

    Decorator adds behavior without changing interface, Facade simplifies but does not adapt interfaces, Proxy controls access. Only Adapter converts interfaces.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Adapter converts incompatible interfaces to expected ones [check]
Hint: Adapter converts interfaces, Decorator adds behavior [check]
Common Mistakes:
2. Given a Vehicle abstraction that requires storing state like speed and fuelLevel, and behavior like accelerate(), should Vehicle be an abstract class or an interface? Why?
easy
A. Abstract class, because it can hold shared state and provide default behavior implementations.
B. Interface, because it allows multiple inheritance and enforces behavior contracts without state.
C. Interface, because Java 8+ interfaces can have default methods and fields for state.
D. Abstract class, because it forces all subclasses to implement all methods explicitly.

Solution

  1. Step 1: Analyze state and behavior requirements

    Vehicle needs to hold shared mutable state like speed and fuelLevel, which interfaces cannot hold as fields.

  2. Step 2: Evaluate abstract class vs interface

    Abstract classes can have instance variables and default method implementations, enabling code reuse and shared state. Interfaces cannot hold instance state, only constants.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful abstraction -> abstract class, not interface [check]
Hint: Stateful base -> abstract class; stateless contract -> interface [check]
Common Mistakes:
3. You want to add a WeekendFeeStrategy to the traffic light system's parking fee calculation. According to SOLID principles, what is the minimum change required?
medium
A. Add a boolean flag isWeekend in FeeCalculator and use conditional logic
B. Modify the existing FeeCalculator class to add weekend logic
C. Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it without changing existing classes
D. Create a subclass WeekendFeeCalculator extending FeeCalculator and override methods

Solution

  1. Step 1: Identify applicable SOLID principle

    Open-Closed Principle (OCP) requires classes to be open for extension but closed for modification.

  2. Step 2: Evaluate options for OCP compliance

    Adding a flag with conditional logic violates OCP by modifying existing class; creating a new strategy class and injecting it respects OCP.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    New strategy class + injection -> OCP compliant extension [check]
Hint: OCP: extend with new class, avoid modifying existing [check]
Common Mistakes:
4. In the auction system, the placeBid() method checks if the auction is still open before accepting a bid. Without synchronizing placeBid(), which exact thread interleaving causes two threads to accept bids after the auction closes, resulting in inconsistent state?
medium
A. Thread 1 reads auction open -> false; Thread 2 reads auction open -> true; both reject bids.
B. Thread 1 and Thread 2 both wait on a lock; no bids accepted until lock released.
C. Thread 1 writes bid; Thread 2 reads bid; no race condition occurs because writes are atomic.
D. Thread 1 reads auction open -> true; context switch before bid recorded; Thread 2 reads auction open -> true; both record bids after auction closed.

Solution

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

    Without synchronization, Thread 1 reads auction open as true but is preempted before recording the bid.

  2. Step 2: Thread 2 reads auction open as true and proceeds to record bid as well, both bypassing the closed state check.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Unsynchronized check-then-act -> double acceptance after close [check]
Hint: Check-then-act without sync -> race condition double accept [check]
Common Mistakes:
5. In a vending machine using the State pattern, if the method selectItem() is not synchronized, which exact thread interleaving causes dispensing the same item twice?
medium
A. Thread 1 checks item availability -> true, context switch, Thread 2 checks availability -> true, both dispense item
B. Thread 1 and Thread 2 both wait on a lock, causing deadlock
C. Thread 1 updates inventory, Thread 2 reads old inventory before update
D. Thread 1 calls selectItem(), Thread 2 calls cancel(), both proceed concurrently

Solution

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

    Without synchronization, both threads can read item availability as true before either decrements inventory.

  2. Step 2: Trace the interleaving

    Thread 1 checks availability -> true, context switch; Thread 2 checks availability -> true; both proceed to dispense, causing double dispense.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Unsynchronized check-then-act -> double dispense [check]
Hint: Check-then-act without sync -> double dispense race [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