Facade Pattern
(A Structural Pattern)

Prsented By:
Jainik Patel(112332)
Darshan Darji(112333)
Dhiraj Rajput(112338)
Prashant Goswami(112344)
Facade
 A structural design pattern
•



Decouples interface from implementation

Intent
•
•
•

To provide a unified interface to a set of interfaces in a
subsystem
To simplify an existing interface
Defines a higher-level interface that makes the subsystem
easier to use
Facade Problem & Solution
Client
classes
FACADE

Subsystem
classes
Motivation
• Structuring a system into subsystems helps reduce complexity.
• A common design goal is to minimize the communication and

dependencies between subsystems.
• One way to achieve this goal is to introduce a facade object that

provides a single, simplified interface to the more general
facilities of a subsystem.
Applicability
 Use the Facade pattern when

 Facade to decouple the subsystem for clients and other

subsystems
 To layer your subsystem. Use façade to define an entry point to

each subsystem level. If subsystems are dependent, then you
can simplify the dependencies between them by making them
communicate with each other through their facades.
Facade Structure
Participants
 Facade
 knows which subsystem classes are responsible for a
request.
 delegates client requests to appropriate subsystem objects.
 subsystem classes
 implement subsystem functionality.
 handle work assigned by the Facade object.
Collaborations
 Clients communicate with the subsystem by sending

requests to Facade, which forwards them to the appropriate
subsystem object(s). Although the subsystem objects
perform the actual work, the facade may have to do work of
its own to translate its interface to subsystem interfaces.
Consequences
 The Facade pattern offers the following benefits:


It shields clients from subsystem components, thereby
reducing the number of objects that clients deal with and
making the subsystem easier to use.



It promotes weak coupling between the subsystem and its
clients.



Help in layering the systems helps elements circular
dependency.
Implementation
• Sub System easier to use
• Strongly Coupled.
• We're going to create a MobileShope interface and concrete

classes implementing the MobileShope interface. A facade class
ShopeKeeperFacade is defined as a next step.
• ShopeKeeperFacade class uses the concrete classes to delegates

user calls to these classes FacadeClient, our Client class will use
ShopeKeeperFacade class to show the results.
Example Class Diagram
Example Class Diagram
Facade Pattern
– Related Pattern
– Abstract Factory Pattern
– Common Variations
• Key: Don’t add new behavior, just simplify interface to existing
behavior
– Java API Usage
• java.net.URL
– client can use it without being aware of classes that allow it to
work
– client can use classes like URLConnection directly if they
choose
Facadepattern

Facadepattern

  • 1.
    Facade Pattern (A StructuralPattern) Prsented By: Jainik Patel(112332) Darshan Darji(112333) Dhiraj Rajput(112338) Prashant Goswami(112344)
  • 2.
    Facade  A structuraldesign pattern •  Decouples interface from implementation Intent • • • To provide a unified interface to a set of interfaces in a subsystem To simplify an existing interface Defines a higher-level interface that makes the subsystem easier to use
  • 3.
    Facade Problem &Solution Client classes FACADE Subsystem classes
  • 4.
    Motivation • Structuring asystem into subsystems helps reduce complexity. • A common design goal is to minimize the communication and dependencies between subsystems. • One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.
  • 5.
    Applicability  Use theFacade pattern when  Facade to decouple the subsystem for clients and other subsystems  To layer your subsystem. Use façade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other through their facades.
  • 6.
  • 7.
    Participants  Facade  knowswhich subsystem classes are responsible for a request.  delegates client requests to appropriate subsystem objects.  subsystem classes  implement subsystem functionality.  handle work assigned by the Facade object.
  • 8.
    Collaborations  Clients communicatewith the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem object(s). Although the subsystem objects perform the actual work, the facade may have to do work of its own to translate its interface to subsystem interfaces.
  • 9.
    Consequences  The Facadepattern offers the following benefits:  It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use.  It promotes weak coupling between the subsystem and its clients.  Help in layering the systems helps elements circular dependency.
  • 10.
    Implementation • Sub Systemeasier to use • Strongly Coupled. • We're going to create a MobileShope interface and concrete classes implementing the MobileShope interface. A facade class ShopeKeeperFacade is defined as a next step. • ShopeKeeperFacade class uses the concrete classes to delegates user calls to these classes FacadeClient, our Client class will use ShopeKeeperFacade class to show the results.
  • 11.
  • 12.
  • 13.
    Facade Pattern – RelatedPattern – Abstract Factory Pattern – Common Variations • Key: Don’t add new behavior, just simplify interface to existing behavior – Java API Usage • java.net.URL – client can use it without being aware of classes that allow it to work – client can use classes like URLConnection directly if they choose