Facade Design Pattern – Structural Patterns in Java

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

You could purchase my Spring 5 book that is with title name “Spring 5 Design Patterns“. This book is available on the Amazon and Packt publisher website. Learn various design patterns and best practices in Spring 5 and use them to solve common design problems. You could use author discount to purchase this book by using code- “AUTHDIS40“.
Spring-5-Design-Pattern

UML Class Diagram for Facade Design Pattern

There are following classes and objects participating in this pattern are:

Facade Design Pattern
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.

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.

Add Comment