Facade Design Pattern is nothing but it simply interface of interfaces to simplify interactions between the client code and subsystem classes. This design comes under the GOF Structural Design Pattern. Facade provides clients with access to the system but conceals the working of the system and its complexities. The pattern creates one class consisting of user functions and delegates provide calling facilities to the classes belonging to the systems.
Facade Design Pattern
According to the Gang of Four:
Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
This pattern involves a single class which provides simplified methods required by client and delegates calls to methods of existing system classes.
Spring 5 Design Pattern Book
UML Class Diagram for Facade Design Pattern
There are following classes and objects participating in this pattern are:
Facade (BankingServiceFacade)
- This is a Facade interface knows which subsystem classes are responsible for a request. This interface is responsible to delegate client requests to appropriate subsystem objects.
Subsystem classes (AccountService, TransferService, PaymentService)
- These interfaces are actually subsystem functionality functionalities of Banking Process System application. These are responsible to handle process assigned by the Facade object. No interfaces in this category has reference of Facade object, even they don’t have implementation details of Facade. These are totally independent from Facade object.
also read:
Pros of the Facade Pattern
There are following pros of using this facade pattern.
- Facade pattern reduces complexities for client to interact with subsystems.
- This pattern consolidates all the business services as single interface to make more understandable.
- It reduces dependencies of client code on the inner workings of a system.
Cons of the Facade Pattern
There are following cons of using this facade pattern.
- It leads to a larger API to maintain
- It hides the important information in useless information
Applicability
Suppose you are designing a system, this system has very large number of independent classes and also has set of services to be implementing. This system is going to be very complex, Facade pattern comes into picture and reduce complexities of the larger system and simplifies interactions of the client code with the set of classes of subsystem of the large complex system.
Sample Implementation of the Facade Design Pattern
Suppose you want to develop an bank enterprise application with the large number services some of them as AccountService for getting the Account by accountId, PaymentService for payment gateway service and TransferService is using for actually amount transfer from one account to another account. A client code of the application interacts with these services for a amount transfer from one account to another account. This is how different clients interact with the amount transfer process of the bank system as below:
This interface is know as Facade interface, it is based the Facade pattern, it is a simple way to interact with the subsystems.
Step 1: Create an interface.
Account.java
/** * */ package com.doj.patterns.structural.facade; /** * @author Dinesh.Rajput * */ public interface Account { void accountType(); }
Step 2: Create concrete classes implementing the same interface.
SavingAccount.java
/** * */ package com.doj.patterns.structural.facade; /** * @author Dinesh.Rajput * */ public class SavingAccount implements Account { @Override public void accountType() { System.out.println("SAVING ACCOUNT"); } }
Step 3: Create a facade interface.
BankingServiceFacade.java
package com.doj.patterns.structural.facade; public interface BankingServiceFacade { void moneyTransfer(); }
Step 4: Create a facade class.
BankingServiceFacadeImpl.java
package com.doj.patterns.structural.facade; /** * @author Dinesh.Rajput * */ public class BankingServiceFacadeImpl implements BankingServiceFacade{ @Override public void moneyTransfer() { if(PaymentService.doPayment()){ Account fromAccount = AccountService.getAccount("1"); Account toAccount = AccountService.getAccount("2"); TransferService.transfer(1000, fromAccount, toAccount); } } }
Step 5: Create a service classes.
AccountService.java
package com.doj.patterns.structural.facade; /** * @author Dinesh.Rajput * */ public class AccountService { public static Account getAccount(String accountId) { return new SavingAccount(); } }
PaymentService.java
package com.doj.patterns.structural.facade; /** * @author Dinesh.Rajput * */ public class PaymentService { public static boolean doPayment(){ return true; } }
TransferService.java
package com.doj.patterns.structural.facade; /** * @author Dinesh.Rajput * */ public class TransferService { public static void transfer(int amount, Account fromAccount, Account toAccount) { System.out.println("Transfering Money"); } }
Step 6: Use the facade to use various type of services.
FacadePatternDemo.java
package com.doj.patterns.structural.facade; /** * @author Dinesh.Rajput * */ public class FacadePatternDemo{ public static void main(String[] args) { BankingServiceFacade serviceFacade = new BankingServiceFacadeImpl(); serviceFacade.moneyTransfer(); } }
Step 7: Let’s run this demo class and verify the output.
Transfering Money
Facade Vs Mediator Design Pattern
Mediator design pattern may look very similar to facade design pattern in terms of abstraction. Mediator abstracts the functionality of the subsystems in this way it is similar to the facade pattern. In the implementation of mediator pattern, subsystem or peers components are aware of the mediator and that interact with it. In the case of facade pattern, subsystems are not aware of the existence of facade. Only facade talks to the subsystems.