October 28, 2023

1. Façade
Design
Pattern
Presented by
Masoud Sadrnezhaad
October 28, 2023

2. Table of contents
When to apply the Façade
pattern in software design?
Classes, Instances, States,
SOLID Principles
Exploring the concept and
purpose of façade pattern.
How clients interact with the
Façade and some codes.
Visual representation of the
pattern's structural diagram
Abstract Factory, Mediator,
Singleton
01
04
02
05
03
06
Object-Oriented Introduction Diagrams
Applicability Sample Code Related Patterns

3. Object-Oriented
01
Classes, Instances, States, SOLID Principles

4. Single Responsibility Principle

5. Open-Closed Principle

6. Liskov Substitution Principle

7. Interface Segregation Principle

8. Dependency Inversion Principle

9. Introduction
02
Exploring the concept and purpose of
façade pattern.

10. Design Patterns
Design Patterns
● Best practices for software development
recurring design problems
● Includes problem descriptions, solutions, and
application guidelines.
● Provide implementation hints and examples.
● Illustrate class and object relationships.
Goal of Design Patterns
● Understand the problem and matching it with
some pattern
● Making the present design reusable for the
future usage
● Speed up development with proven
approaches.

11. As the name façade suggests, it means
"the face of the building."

12. Façade Pattern
Analogy
● A glass face of a building hides its complexities from passersby.
● Similarly, the facade design pattern conceals system complexities.
● The facade pattern uses a single class with simplified methods for client interaction.
● It delegates calls to existing system class methods.
● When placing a phone order, the operator serves as a facade.
● The operator offers a simple voice interface to shop services, payment, and delivery.
● Bank sample
Pronunciation is /fəˈsɑːd/
A part of Gang of Four
design patterns (23 others).
It comes under the
“Structural” category.

13. Diagrams
03
Visual representation of the pattern's
structural diagram.

14. Structural Diagram 1

15. Structural Diagram 2

16. Applicability
04
When to apply the Façade pattern in
software design?

17. ● Facade pattern simplifies access to complex
subsystems.
● Subsystems tend to become more complex over
time, leading to smaller classes.
● Facade pattern enhances subsystem reusability
and customization but can complicate things for
non-customizing clients.
● Facades provide a default view for most clients,
allowing customization for those who need it.
● Facades separate subsystems from clients and
other subsystems, promoting independence and
portability.
● Use facades as entry points for subsystems to
simplify interactions between dependent
subsystems.
Applicability

18. ● Facade simplifies client-subsystem interactions.
● Promotes loose coupling between subsystem
and clients, allowing changes without impacting
clients.
● Helps manage complex dependencies and
circular relationships in a system.
● Reduces compilation dependencies in large
software systems, saving time when making
changes.
● Eases porting to other platforms by minimizing
dependencies.
● Doesn't prevent direct use of subsystem classes
when needed, providing flexibility for clients.
Consequences

19. Sample Code
05
How clients interact with the Façade and
some codes.

20. Sample Code
from __future__ import annotations
class Facade:
"""
The Facade class provides a simple interface to the complex logic of one or
several subsystems. The Facade delegates the client requests to the
appropriate objects within the subsystem. The Facade is also responsible for
managing their lifecycle. All of this shields the client from the undesired
complexity of the subsystem.
"""
def __init__(self, subsystem1: Subsystem1, subsystem2: Subsystem2) -> None:
"""
Depending on your application's needs, you can provide the Facade with
existing subsystem objects or force the Facade to create them on its
own.
"""
self._subsystem1 = subsystem1 or Subsystem1()
self._subsystem2 = subsystem2 or Subsystem2()

21. Sample Code (Contd)
class Facade:
def operation(self) -> str:
"""
The Facade's methods are convenient shortcuts to the sophisticated
functionality of the subsystems. However, clients get only to a fraction
of a subsystem's capabilities.
"""
results = []
results.append("Facade initializes subsystems:" )
results.append(self._subsystem1.operation1())
results.append(self._subsystem2.operation1())
results.append("Facade orders subsystems to perform the action:" )
results.append(self._subsystem1.operation_n())
results.append(self._subsystem2.operation_z())
return "n".join(results)

22. Sample Code (Contd)
class Subsystem1:
"""
The Subsystem can accept requests either from the facade or client directly.
In any case, to the Subsystem, the Facade is yet another client, and it's
not a part of the Subsystem.
"""
def operation1(self) -> str:
return "Subsystem1: Ready!"
# ...
def operation_n (self) -> str:
return "Subsystem1: Go!"

23. Sample Code (Contd)
class Subsystem2:
"""
Some facades can work with multiple subsystems at the same time.
"""
def operation1(self) -> str:
return "Subsystem2: Get ready!"
# ...
def operation_z (self) -> str:
return "Subsystem2: Fire!"

24. Sample Code (Contd)
def client_code (facade: Facade) -> None:
"""
The client code works with complex subsystems through a simple interface
provided by the Facade. When a facade manages the lifecycle of the
subsystem, the client might not even know about the existence of the
subsystem. This approach lets you keep the complexity under control.
"""
print(facade.operation(), end="")
if __name__ == "__main__":
# The client code may have some of the subsystem's objects already created.
# In this case, it might be worthwhile to initialize the Facade with these
# objects instead of letting the Facade create new instances.
subsystem1 = Subsystem1()
subsystem2 = Subsystem2()
facade = Facade(subsystem1, subsystem2)
client_code(facade)

25. Sample Code Output
Facade initializes subsystems:
Subsystem1: Ready!
Subsystem2: Get ready!
Facade orders subsystems to perform the action:
Subsystem1: Go!
Subsystem2: Fire!

26. Related Patterns
06
Abstract Factory, Mediator, Singleton

27. Related Patterns
Abstract Factory
● Work with Facade to create subsystem objects uniformly
and independently from the subsystem.
● Abstract Factory can also replace Facade to hide
platform-specific classes.
Mediator.
● Abstracts existing class functionality, but it centralizes
communication between colleague objects, keeping
functionality out of them
● colleagues communicate with the mediator, not directly with
each other, while in Facade, it simplifies subsystem object
interfaces but doesn't introduce new functionality.
Singleton
● T
ypically, only one Facade object is needed, often
implemented as a Singleton.

28. Resources
● Gamma, E., Helm, R., Johnson, R., Vlissides, J. and Patterns, D., 1995.
Elements of Reusable Object-Oriented Software. Design Patterns.
● https://refactoring.guru/design-patterns
● https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pic
tures-b34ce2f1e898

29. Thanks :)
Do you have any questions?
masoud@hbc.ir
smm.sadrn.com