Facade pattern in LLD - System Design Guide

Problem Statement

When a system has many complex classes and interfaces, users or other parts of the system struggle to interact with it easily. This complexity leads to errors, confusion, and slower development because clients must understand many details to use the system.

Solution

The Facade pattern provides a simple interface that wraps the complex parts of the system. It hides the internal complexity and offers a single, easy-to-use entry point. Clients interact with this facade instead of dealing with many classes directly, making the system easier to use and maintain.

Architecture

Client

↓

Facade

↓

Subsystem A

This diagram shows the Client interacting only with the Facade, which internally communicates with multiple complex subsystems.

Trade-offs

✓ Pros

→

Simplifies client interaction by hiding complex subsystem details.

→

Reduces dependencies between client code and subsystems, improving maintainability.

→

Improves code readability and usability by providing a clear, unified interface.

✗ Cons

→

Can become a god object if it tries to handle too many responsibilities.

→

Adds an extra layer, which might slightly impact performance in very high-throughput systems.

→

May hide useful subsystem features that clients might need, limiting flexibility.

Use when a system has multiple complex subsystems and clients need a simple interface to interact with them, especially when you want to reduce coupling and improve usability.

Avoid when the system is simple or when clients need full access to all subsystem features without restrictions.

Real World Examples

Amazon

Amazon uses facade-like APIs to provide simple interfaces for complex backend services like payment processing and inventory management, so frontend teams can integrate easily without knowing internal details.

Netflix

Netflix uses facade patterns in their client SDKs to hide complex streaming and recommendation subsystems behind simple APIs for app developers.

LinkedIn

LinkedIn applies facade patterns to unify access to multiple data sources and services, simplifying the client-side code for profile and feed features.

Code Example

The before code shows the client directly calling multiple subsystem methods, which is complex and error-prone. The after code introduces a Facade class that wraps subsystem calls into a single simple method. The client now calls only the Facade, reducing complexity and dependencies.

LLD

### Before applying Facade pattern (complex client code):

class SubsystemA:
    def operation_a1(self):
        return "SubsystemA: Operation A1"
    def operation_a2(self):
        return "SubsystemA: Operation A2"

class SubsystemB:
    def operation_b1(self):
        return "SubsystemB: Operation B1"
    def operation_b2(self):
        return "SubsystemB: Operation B2"

# Client must interact with both subsystems directly
sub_a = SubsystemA()
sub_b = SubsystemB()
result = []
result.append(sub_a.operation_a1())
result.append(sub_a.operation_a2())
result.append(sub_b.operation_b1())
result.append(sub_b.operation_b2())
print('\n'.join(result))

### After applying Facade pattern (simplified client code):

class Facade:
    def __init__(self):
        self.sub_a = SubsystemA()
        self.sub_b = SubsystemB()
    def simple_operation(self):
        results = []
        results.append(self.sub_a.operation_a1())
        results.append(self.sub_b.operation_b2())
        return '\n'.join(results)

# Client interacts only with Facade
facade = Facade()
print(facade.simple_operation())

Alternatives

Adapter pattern

Adapter changes an existing interface to a different one expected by clients, while Facade provides a new simplified interface over multiple interfaces.

Use when: Choose Adapter when you need to make incompatible interfaces work together without changing their code.

Proxy pattern

Proxy controls access to a single object, often adding security or caching, whereas Facade simplifies interaction with multiple objects.

Use when: Choose Proxy when you need to control or add behavior to access of a single object.

Summary

Facade pattern simplifies complex systems by providing a single easy-to-use interface.

It reduces dependencies and improves maintainability by hiding subsystem details.

Clients interact with the facade instead of many subsystems, making code cleaner and easier to use.

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