Facade Pattern
A. R. Dani
Facade Pattern: Why and What?
• Subsystems often get complex as they evolve.
• Need to provide a simple interface to many, often
small, classes. But not necessarily to ALL classes of
the subsystem.
• Façade provides a simple default view good enough
for most clients.
• Facade decouples a subsystem from its clients.
• A façade can be a single entry point to each
subsystem level. This allows layering.
2
The Facade Pattern: The Problem
• Its main objective is to provide a unified higher level
interface to a set of interfaces in a subsystem
• It makes the subsystem easier to use
• It provides a simple interface to a complex subsystem
• It decouples a subsystem from clients and other
subsystems
• It helps in creating a layered subsystems by providing
an interface to each subsystem level
Facade Pattern
• Suppose that you have developed a system for
handing Point of Sales Terminals (POS).
• A Sale can be entered and bills can be calculated
• Suppose that there are different rules for validation of
sales.
• These rules can be dynamically created
Facade Pattern: Example
• Assume that new rules are to be created to
invalidate an action:
– Suppose that when a new Sale is created, it
will be paid by a gift certificate
– Only one item can be purchased using a gift certificate.
– Hence, subsequent enterItem operations must be
invalidated in some cases. (Which ones?)
How does a designer factor out the handling of
such rules?
5
Facade Pattern: Example
• Define a “rule engine” subsystem (e.g.
POSRuleEngineFacade).
• It evaluates a set of rules against an operation and
indicates if the rule has invalidated an operation.
• Calls to this façade are placed near the start of the methods that need to be validated.
– Example: Invoke the façade to check if a new salesLineItem created
by makeLineItem is valid or not.
6
Facade Pattern
• Facade:
• It Knows which subsystem classes are responsible for
a request
• It Delegates clients requests to appropriate
subsystem objects
• Subsystems Classes
– Implement the subsystem functionality
– Handle work assigned by the Facade object
– Have no knowledge of the Facade object i.e. keep
no reference to it
Facade Pattern
• In this pattern Clients send their request to Facade
• Façade Object forwards them to the appropriate
subsystem object
• It is widely Used In Compilers
• Resource Management Functions
Facade Pattern: Solution
Client Classes
Facade
Subsystem classes
9
Facade Pattern: Problem
Client Classes
Need to communicate
with
Subsystem classes
10
Facade Pattern
Facade Pattern
Example: A compiler
Compiler Invocations
Compile()
Stream
Scanner Token
BytecodeStream
Parser Symbol
CodeGenerator
PnodeBuilder Pnode
StatementNode ExpressionNode
RISCCodegenerator StackMachineCodegenerator
13
Facade Pattern
Facade Pattern
• It shields clients from subsystem components
thereby reducing the number of objects that clients
deal with thus making the subsystem easier to use
• It promotes weak coupling between the subsystem
and its clients allowing components of the subsystem
to change without affecting the clients
• It reduces compilation dependencies in large
software systems
• It does not prevent applications from using
subsystem classes if they need to
Facade Pattern
• The coupling between clients and subsystems can be
reduced further by making Facade an abstract class
with concrete subclasses for different
implementations. - A Facade object with different
subsystem objects,
• It can be customized by replacing one or more of the
subsystem objects
• Public and Private Subsystem classes
• The Façade is a part of the public Interface of a
subsystem , so we can have private subsystem classes
Facade Pattern: Participants and Communication
• Participants: Façade and subsystem classes
• Clients communicate with subsystem classes by sending
requests to façade.
• Façade forwards requests to the appropriate subsystem
classes.
• Clients do not have direct access to subsystem classes.
