1. Facade
From
Main Entry: fa·cade Variant(s): also fa·çade /f&-'säd/ Function: noun Etymology: French façade, from Italian facciata, from faccia face, from (assumed) Vulgar Latin facia Date: circa : the front of a building; also : any face of a building given special architectural treatment <a museum's east facade> 2 : a false, superficial, or artificial appearance or effect
Fall 2009
ACS R McFadyen

2. Facade
Problem: There are a set of classes, a subsystem, that you need to interact with for some purpose, but you don’t want to create dependencies on this subsystem.
Solution: Create a class that wraps this subsystem. The wrapper will define an interface that hides the details (classes, methods) of the subsystem.
The façade is a “front-end” object that defines a single point of entry to the subsystem’s services.
A façade,
a wrapper
Showing the classes as a package (a subsytem)
Fall 2009
ACS R McFadyen

3. NextGen POS is a system to be sold to many customers.
Facade
Text example.
NextGen POS is a system to be sold to many customers.
Customers will want to customize NextGen POS
Example: Payment rules may vary for gift certificates. How are gift certificates to be handled:
One per customer per purchase?
No change is returned - another gift certificate issued?
To allow flexibility, it is desired to reduce the impact of changes to the rest of the system
To reduce the impact, the Façade pattern is applied and the subsytem will be hidden behind a single object
Fall 2009
ACS R McFadyen

4. Figure
Sale objects, in the Domain package, access the POS Rule Engine via the façade in the POSRuleEngine package
if ( POSRuleEngineFacade.getInstance().isInvalid(…) ...
Public class Sale …
Fall 2009
ACS R McFadyen

5. Façades are normally accessed via the Singleton pattern.
if ( POSRuleEngineFacade.getInstance().isInvalid(…) ...
Public class Sale …
Singleton is a pattern whereby one instance of an object of some class is created/allowed. The class will have a static method that returns the singleton.
Façades are normally accessed via the Singleton pattern.
Fall 2009
ACS R McFadyen

6. :POSRuleEngineFacade
:Sale
:POSRuleEngineFacade
:SalesLineItem
makeLineItem()
isInvalid (…) .
[valid] add (…)
Fall 2009
ACS R McFadyen

7. Example: (from Design Patterns Explained by Shalloway & Trott)
Suppose a client object must deal with Databases, Models, and Elements. The client must first open the Database, then get a Model, then queries the Model for Elements, and finally gets Elements.
I.e.
Database
Client
Model
Element
Fall 2009
ACS R McFadyen

8. Example: (from Design Patterns Explained by Shalloway & Trott)
It may be easier to create a Database Façade that can be used by clients
I.e.
ClientA
Database
Db Facade
ClientB
Model
Element
ClientC
To use the database, one only needs to become aware of DbFacade, and learn how to use it.
Fall 2009
ACS R McFadyen

9. Example: (from Design Patterns Explained by Shalloway & Trott)
It may be easier to create a Database Façade that can be used by clients
I.e.
ClientA
Database
Db Facade
ClientB
Model
Element
ClientC
To use the database, one only needs to become aware of DbFacade, and learn how to use it.
Fall 2009
ACS R McFadyen

10. (from Design Patterns Explained by Shalloway & Trott)
When to use Facade
(from Design Patterns Explained by Shalloway & Trott)
To create a simpler interface: number of methods, number of objects one has to deal with
The system being hidden may have an older, more complex interface
The cost of developing the façade, and of developers learning the new interface may be less than learning the old one
You may only be needing a subset of the functionality
You may want to augment the functionality of the system
To facilitate tracking system usage – by forcing all requests to go through a Façade class, one can easily track the usage.
To facilitate subsystem replacement – only one class is affected, the Façade class. This is the motivation in Larman’s example.
Fall 2009
ACS R McFadyen