Enterprise Integration Zone is brought to you in partnership with:

Mainak is an experienced Technology Consultant specializing in JEE, Web Development and Open source technologies. He is currently based out of United Kingdom. He is die hard technology enthusiast trying to explore the latest in the world of technology. In past time he loves blogging on his website: http://idiotechie.com. Mainak is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Façade Design Pattern – Design Standpoint

12.06.2012
| 6658 views |
  • submit to reddit

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






Published at DZone with permission of Mainak Goswami, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sat, 2012/12/08 - 4:43pm

Hopefully the facade client interface is not dependent on the subsystem interface, so only the implementation of the facade methods will need to be changed.  I think that's what you meant.

Mainak Goswami replied on Sat, 2012/12/08 - 7:43pm in response to: Lund Wolfe

That's right.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.