DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Façade Design Pattern – Design Standpoint

Mainak Goswami user avatar by
Mainak Goswami
·
Dec. 06, 12 · Interview
Like (0)
Save
Tweet
Share
18.74K Views

Join the DZone community and get the full member experience.

Join For Free

In our previous article we have described about the Adapter Design Pattern. In today’s article we are going to show about another such Gang of Four Structural patterns.  As the name suggests structural pattern is used to form a larger object structure from many different objects. Façade pattern is one such pattern which provides a simplified interface to a set of interfaces within a system and thus it hides the complexities of the subsystem from the client.

When to use Façade Pattern?

Layering: Facade pattern can be used in JEE applications for creating a layer to abstract and unify the related interfaces in the application. Use of a facade will define an entry point to each subsystem level and thus make them communicate only through their facades; this can simplify the dependencies between them.

Façade makes the API and libraries easier to use which is good for maintenance and readability. It can also collate and abstract various poorly designed APIs with a single simplified API.

It also reduces dependencies of the external code on the inner working of the libraries and thus providing flexibility.

Facade Design Pattern structure

Facade Design Pattern structure

In the above structure for Façade pattern the Façade class insulates the subsystem from the client. The client only interacts with the Façade class without knowing about the subsystem classes.

Example:

Let’s take an example of Order processing online website. The client has placed an order without having knowledge of how internal classes are functioning. Once the order is placed the façade class layer calls the methods of the subsystems like Inventory for inventory check and Payment for processing of the payment. After processing it returns the control to the client class with the confirmation about the order being processed.

Sequence Diagram:

Facade Design Sequence Diagram

Facade Design Sequence Diagram

Code Example:

Inventory.java -

public class Inventory {
    public String checkInventory(String OrderId) {
        return "Inventory checked";
    }
}

Payment.java

public class Payment {
    public String deductPayment(String orderID) {
        return "Payment deducted successfully";
 
    }
}

OrderFacade.java

public class OrderFacade {
    private Payment pymt = new Payment();
    private Inventory inventry = new Inventory();
 
    public void placeOrder(String orderId) {
        String step1 = inventry.checkInventory(orderId);
        String step2 = pymt.deductPayment(orderId);
        System.out
                .println("Following steps completed:" + step1
                        + " & " + step2);
    }
}

Client.java

public class Client {
  public static void main(String args[]){
      OrderFacade orderFacade = new OrderFacade();
      orderFacade.placeOrder("OR123456");
      System.out.println("Order processing completed");
  }
}

Benefits:

  • We can use the façade pattern to collate all the complex method calls and related code blocks and channelizes it through one single Façade class. In this way with respect to client there is only one single call. Even if we make changes to the subsystem packages / class and their logic there is no impact to the client call. In short this increases loose coupling.
  • It makes easier to use and maintain creating a more structured environment and reduces dependencies between libraries or other packages.

Drawbacks/Consequences:

  • One of the drawback is that the subsystem methods are connected to the Façade layer. If the structure of the subsystem changes then it will require subsequent change to the Façade layer and client methods.

Interesting points:
Façade pattern might be confused with mediator pattern. Mediator also abstracts the functionality of the subsystem in similar manner to façade. However there is a subtle difference between both these patterns. In case of Mediator pattern the subsystem is aware of the mediator, however in case of Façade the subsystem does not know anything about the façade. It’s a one way communication from Façade to subsystem.

Façade used in Java API
javax.servlet.http.HttpSession
javax.servlet.http.HttpServletRequest
javax.servlet.http.HttpServletResponse
javax.faces.context.ExternalContext






Design

Published at DZone with permission of Mainak Goswami, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Upgrade Guide To Spring Data Elasticsearch 5.0
  • Microservices Discovery With Eureka
  • Mr. Over, the Engineer [Comic]
  • 5 Factors When Selecting a Database

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: