Bird
Raised Fist0

Facade Pattern - Simplifying Complex Subsystems for Clients

LLDeasyInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Class Trace
Step 1/3
Facade Singleton

Facade is a Singleton with private subsystem fields composed inside it to manage lifecycle.

🎯 Tests whether candidate knows volatile and synchronized getInstance() are needed to ensure thread-safe lazy Singleton initialization in Java.
public class Facade {
    private static volatile Facade instance;
    private SubsystemA subA;
    private SubsystemB subB;
    private SubsystemC subC;

    private Facade() {
        subA = new SubsystemA();
        subB = new SubsystemB();
        subC = new SubsystemC();
    }

    public static synchronized Facade getInstance() {
        if (instance == null) {
            instance = new Facade();
        }
        return instance;
    }
Facade composition with Subsystems

Facade composes SubsystemA, SubsystemB, and SubsystemC, owning their lifecycle and exposing a simplified interface.

🎯 Tests understanding of composition relationship where Facade controls subsystems lifecycle, enforcing strong encapsulation and lifecycle ownership.
public synchronized void operation() {
    subA.operationA();
    subB.operationB();
    subC.operationC();
}
Client association with Facade

Client holds an association to Facade and calls its operation method to interact with complex subsystems indirectly.

🎯 Tests whether candidate distinguishes association (Client uses Facade) from composition (Facade owns subsystems), showing correct lifecycle ownership.
public class Client {
    private Facade facade = Facade.getInstance();
    public void doWork() {
        facade.operation();
    }
}
📐
Class Diagram
Class Diagram
       +----------------+
       |    Facade      |
       | <<Singleton>>  |
       +----------------+
       | -subA: SubsysA |
       | -subB: SubsysB |
       | -subC: SubsysC |
       +----------------+
       | +getInstance():Facade [sync] |
       | +operation():void [sync]     |
       +----------------+
              ◆
              │ composition
              │
       +----------------+
       |  SubsysA       |
       +----------------+
       | +operationA():void |
       +----------------+
              ▲
              │ association
              │
       +----------------+
       |   Client       |
       +----------------+
       | +doWork():void |
       +----------------+
              ─ ─ ─►
              association
              │
       +----------------+
       |  SubsysB       |
       +----------------+
       | +operationB():void |
       +----------------+
              ◆
              │ composition
              │
       +----------------+
       |  SubsysC       |
       +----------------+
       | +operationC():void |
       +----------------+
Design Rationale

This class diagram illustrates the Facade pattern simplifying complex subsystem interactions for clients. The Facade class is implemented as a thread-safe Singleton using a volatile instance and synchronized getInstance() method to prevent unsafe publication. It composes SubsystemA, SubsystemB, and SubsystemC, owning their lifecycle and exposing a unified operation() method. The Client class holds an association to the Facade, invoking its operation() to interact with subsystems indirectly, enforcing the Open-Closed Principle by hiding subsystem complexity. The diagram emphasizes composition lifecycle ownership, Singleton concurrency control, and association usage for client interaction.

Primary Focus

✓ Composition lifecycle + Facade pattern OCP + Singleton volatile usage

Practice

(1/5)
1. In the Meeting Scheduler system, a MeetingManager class has a private constructor and a static synchronized getInstance() method. Which design pattern is applied here, and why is this the correct choice for managing meeting schedules?
easy
A. Singleton pattern, to ensure only one instance manages all meeting schedules and avoids conflicting updates.
B. Factory pattern, because it creates different meeting types dynamically.
C. Builder pattern, to construct complex meeting objects step-by-step.
D. Prototype pattern, to clone existing meeting instances for recurring events.

Solution

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

    The private constructor prevents external instantiation, and the static synchronized getInstance() ensures a single shared instance, matching Singleton pattern characteristics.

  2. Step 2: Reason why Singleton fits MeetingManager

    MeetingManager must coordinate all meetings centrally to avoid conflicting schedules; multiple instances could cause inconsistent state.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Private constructor + synchronized getInstance() -> Singleton pattern [check]
Hint: Private constructor + static getInstance() -> Singleton [check]
Common Mistakes:
2. You need to design a Vehicle abstraction that requires both state (like speed) and behavior (like accelerate()). Should Vehicle be an abstract class or an interface, and why?
easy
A. Interface, because it allows multiple inheritance of state and behavior.
B. Interface, because it can hold state and enforce behavior contracts.
C. Abstract class, because it can hold shared state and provide default behavior implementations.
D. Abstract class, because it cannot have abstract methods.

Solution

  1. Step 1: Analyze state and behavior requirements

    Interfaces cannot hold instance state (fields) but can declare behavior. Abstract classes can hold state and provide default method implementations.

  2. Step 2: Evaluate options

    Interface, because it can hold state and enforce behavior contracts. is incorrect because interfaces cannot hold state. Interface, because it allows multiple inheritance of state and behavior. is wrong as interfaces do not hold state. Abstract class, because it cannot have abstract methods. is false because abstract classes can have abstract methods.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    State + behavior -> abstract class, interfaces lack instance fields [check]
Hint: State needs abstract class; interfaces only declare behavior [check]
Common Mistakes:
3. In a Java class hierarchy, a base class defines a final method that calls several abstract methods which subclasses must implement. Which design pattern is this an example of?
easy
A. Template Method Pattern, because the base class defines the algorithm skeleton and subclasses fill in steps.
B. Strategy Pattern, because subclasses provide interchangeable algorithms.
C. Factory Method Pattern, because the base class creates objects via subclass overrides.
D. Decorator Pattern, because behavior is added dynamically by subclasses.

Solution

  1. Step 1: Identify the role of the final method

    The base class's final method defines the fixed algorithm skeleton, preventing subclasses from changing the overall flow.

  2. Step 2: Recognize abstract methods as extension points

    Subclasses implement abstract methods to fill in specific steps, matching the Template Method pattern's intent.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Base class controls algorithm flow; subclasses customize steps [check]
Hint: Final method fixes flow; subclasses fill steps [check]
Common Mistakes:
4. To support ElectricCar and ChargingSpot in the Wallet System's parking module, what is the minimum change to the current design to maintain extensibility without modifying existing classes?
hard
A. Modify Vehicle base class to include isElectric flag and add ChargingSpot as a subclass of Spot.
B. Create a new ElectricVehicle interface and modify existing Vehicle and Spot classes to implement it.
C. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally.
D. Add logic for ElectricCar and ChargingSpot directly inside existing Vehicle and Spot classes.

Solution

  1. Step 1: Identify extensibility without modifying existing classes

    Adding new enum values and subclasses externally allows extension without changing existing code, preserving OCP.

  2. Step 2: Use external compatibility map update

    Updating SpotCompatibility.COMPATIBILITY_MAP externally avoids modifying existing classes, enabling new vehicle and spot types to integrate cleanly.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New enums + subclass + external map update -> no existing class changes [check]
Hint: Add enums + subclass + external map update -> no existing class change [check]
Common Mistakes:
5. ElectricCar requires ChargingSpots in the parking system using Prototype pattern. What is the minimum change to support this without modifying existing classes?
hard
A. Modify Vehicle base class to include charging logic and add ChargingSpot as a subclass of Spot
B. Add charging logic inside Vehicle clone() and modify SpotCompatibility map inside existing classes
C. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally
D. Create a god-class that handles both ElectricCar and ChargingSpot logic to avoid modifying existing classes

Solution

  1. Step 1: Identify extensibility requirements

    Adding ElectricCar and ChargingSpot must avoid modifying existing classes to respect OCP.

  2. Step 2: Evaluate options for minimal invasive change

    Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map externally adds new enum values and subclasses externally, updating compatibility map without changing existing code. Options B and C modify base classes, violating OCP. Create a god-class that handles both ElectricCar and ChargingSpot logic to avoid modifying existing classes creates god-class, violating SRP and maintainability.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New enums + subclass + external map update -> minimal change, OCP respected [check]
Hint: New enums + subclass + external map -> minimal invasive change [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