Façade Design Pattern – Design standpoint

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

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

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