Facade pattern in LLD - System Design Exercise

Design: Facade Pattern Design

Design a software component that acts as a facade to multiple complex subsystems, simplifying client interaction. Out of scope: detailed implementation of subsystems.

Functional Requirements

FR1: Provide a simplified interface to a complex subsystem

FR2: Hide the complexity of multiple underlying components from the client

FR3: Allow clients to interact with the system easily without knowing internal details

FR4: Support extensibility to add or modify subsystems without affecting clients

Non-Functional Requirements

NFR1: The facade should not add significant performance overhead

NFR2: The design should maintain loose coupling between clients and subsystems

NFR3: The system should be scalable to add more subsystems in the future

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Facade component providing simplified interface

Multiple subsystem components with complex interfaces

Client component interacting only with the facade

Optional adapters or wrappers for subsystems

Design Patterns

Facade pattern for interface simplification

Adapter pattern if subsystem interfaces differ

Proxy pattern for controlling access

Observer pattern if subsystems need to notify facade

Reference Architecture

Client
  |
  v
Facade
 / | \
Subsystem1 Subsystem2 Subsystem3

Components

Facade

Any OOP language (e.g., Java, Python, C#)

Provide a simple unified interface to multiple complex subsystems

Subsystem1

Any OOP language

Handles specific complex operations hidden behind facade

Subsystem2

Any OOP language

Another complex subsystem with its own interface

Subsystem3

Any OOP language

Additional subsystem encapsulated by facade

Client

Any OOP language

Uses facade to interact with subsystems without complexity

Request Flow

1. Client calls a method on the Facade interface

2. Facade translates the call into one or more calls to subsystems

3. Subsystems perform their complex operations internally

4. Facade collects results or handles errors from subsystems

5. Facade returns a simplified response to the Client

Database Schema

Not applicable as this pattern focuses on software component interaction rather than data storage.

Scaling Discussion

Bottlenecks

Facade becoming a monolithic component if too many subsystems are added

Performance overhead if facade calls many subsystems sequentially

Difficulty maintaining facade if subsystems change frequently

Solutions

Modularize facade internally to delegate to smaller facades or handlers

Use asynchronous calls or parallel processing to improve performance

Apply adapter pattern to isolate facade from subsystem changes

Interview Tips

Time: Spend 10 minutes explaining the problem and requirements, 20 minutes designing the facade and subsystems interaction, 10 minutes discussing scaling and trade-offs, and 5 minutes answering questions.

Explain how facade simplifies client interaction by hiding subsystem complexity

Discuss how loose coupling is maintained between facade and subsystems

Mention extensibility to add or modify subsystems without affecting clients

Highlight potential bottlenecks and how to mitigate them

Show understanding of related design patterns like Adapter and Proxy

Practice

1. What is the main purpose of the Facade pattern in system design?

easy

A. To make the system slower by adding extra layers

B. To increase the number of classes in a system

C. To provide a simple interface to a complex system

D. To replace all subsystem classes with one class

Solution

1. Step 1: Understand the Facade pattern role

   The Facade pattern is designed to simplify interactions by providing a single interface to a complex system.

2. Step 2: Compare options with the pattern's purpose

   To provide a simple interface to a complex system correctly states the purpose. Options A, B, and C describe incorrect or harmful effects.

3. Final Answer:

   To provide a simple interface to a complex system -> Option C

4. Quick Check:

   Facade pattern = Simple interface [OK]

Hint: Facade means simple front for complex system [OK]

Common Mistakes:

• Thinking Facade replaces all classes
• Believing Facade adds complexity
• Confusing Facade with Singleton pattern

2. Which of the following is the correct way to define a Facade class method in a typical object-oriented language?

easy

A. private void complexOperation() { subsystem1.action(); }

B. public int complexOperation() { subsystem1.action(); subsystem2.action(); return 0; }

C. void complexOperation() { return subsystem1.action(); }

D. public void complexOperation() { subsystem1.action(); subsystem2.action(); }

Solution

1. Step 1: Identify Facade method visibility and calls

   Facade methods are usually public to expose simplified operations and call multiple subsystems internally.

2. Step 2: Check each option's correctness

   public void complexOperation() { subsystem1.action(); subsystem2.action(); } is public and calls multiple subsystems, matching Facade pattern. private void complexOperation() { subsystem1.action(); } is private, so not accessible. void complexOperation() { return subsystem1.action(); } returns a value but calls only one subsystem. public int complexOperation() { subsystem1.action(); subsystem2.action(); return 0; } returns int unnecessarily.

3. Final Answer:

   public void complexOperation() { subsystem1.action(); subsystem2.action(); } -> Option D

4. Quick Check:

   Facade method = public + multiple calls [OK]

Hint: Facade methods are public and call multiple subsystems [OK]

Common Mistakes:

• Making Facade methods private
• Returning values unnecessarily
• Calling only one subsystem inside Facade

3. Given this Facade code snippet, what will be the output?

class SubsystemA {
  void operationA() { print('A'); }
}
class SubsystemB {
  void operationB() { print('B'); }
}
class Facade {
  SubsystemA a = SubsystemA();
  SubsystemB b = SubsystemB();
  void doWork() {
    a.operationA();
    b.operationB();
  }
}
void main() {
  Facade f = Facade();
  f.doWork();
}

medium

A. BA

B. AB

C. A B

D. No output

Solution

1. Step 1: Trace Facade's doWork method calls

   doWork calls operationA() then operationB(), which print 'A' and 'B' respectively.

2. Step 2: Determine output sequence

   Since operationA prints 'A' first, then operationB prints 'B', output is 'AB' without spaces.

3. Final Answer:

   AB -> Option B

4. Quick Check:

   Facade calls order = AB [OK]

Hint: Follow method calls in order to find output [OK]

Common Mistakes:

• Assuming output is 'BA' reversing calls
• Expecting spaces between prints
• Thinking no output due to missing return

4. Identify the error in this Facade implementation:

class Subsystem {
  void action() { print('Action'); }
}
class Facade {
  Subsystem subsystem;
  void doTask() {
    subsystem.action();
  }
}
void main() {
  Facade f = Facade();
  f.doTask();
}

medium

A. Subsystem object is not initialized before use

B. Facade class should not call subsystem methods

C. doTask method should return a value

D. Subsystem class should be abstract

Solution

1. Step 1: Check subsystem object usage in Facade

   The Facade has a subsystem field but never initializes it before calling action(), causing a null reference error.

2. Step 2: Validate other options

   Facade class should not call subsystem methods is wrong because Facade should call subsystem methods. doTask method should return a value is not required. Subsystem class should be abstract is unnecessary.

3. Final Answer:

   Subsystem object is not initialized before use -> Option A

4. Quick Check:

   Uninitialized object = runtime error [OK]

Hint: Always initialize objects before calling methods [OK]

Common Mistakes:

• Ignoring null object initialization
• Thinking Facade should not call subsystems
• Expecting return values unnecessarily

5. You are designing a home automation system with many devices: lights, thermostat, security cameras, and music system. How would applying the Facade pattern help in this scenario?

hard

A. Create a single HomeAutomationFacade class that provides simple methods like turnOnAll() and setTemperature() to control all devices

B. Replace all device classes with one large class containing all device logic

C. Make each device class inherit from a common Facade superclass

D. Use Facade pattern to split each device into smaller classes

Solution

1. Step 1: Understand Facade's role in simplifying complex systems

   Facade groups multiple subsystem calls into simple methods, hiding complexity from users.

2. Step 2: Apply this to home automation

   Create a single HomeAutomationFacade class that provides simple methods like turnOnAll() and setTemperature() to control all devices correctly describes creating a Facade class with simple methods controlling multiple devices. Options A, B, and D misunderstand Facade's purpose.

3. Final Answer:

   Create a single HomeAutomationFacade class that provides simple methods like turnOnAll() and setTemperature() to control all devices -> Option A

4. Quick Check:

   Facade = simple interface for complex devices [OK]

Hint: Facade groups complex calls into simple methods [OK]

Common Mistakes:

• Merging all logic into one big class
• Confusing Facade with inheritance
• Splitting devices further instead of simplifying