Imagine a car engine!
When you want to control the engine as a driver, you get into the divers seat. But, when you want to work on it as a mechanic, you open its bonnet.
Even when we are talking about the same engine, it has exposed two separate facades for two different types of users.

Its a structural design pattern that provides context specific interfaces to simplify and make the integration of a complex system easy for the clients.

A complex system may consists of multiple sub-systems. But, we need not expose everything, expecting the clients to figure out what they need. Instead we can identify what the client needs from our system to build an interface, so that it provides a simplified view of our system. We call such a context specific interface as a facade.

A facade may provide many key advantages while exposing a complex systems as listed below.

Benefits of using Facades

1. Provides simplified views of the our system, matching to their usage
   • Since different user groups have different views, we may create multiple facades to meet their needs. For instance an admin and a normal user can have their own facades.
   • In case there are too many features to accomodate, we may break our facades using logical groups.
2. Provides the flexibility to redesign by decoupling the sub-systems from the clients
3. Enable us to simplify our usage by creating higher order services
   • Because of the facade, we can combine multiple dependent calls to the sub-systems to build higher order services.
   • Without a facade, we may force the clients to build these services on their own.
     • In case of remote services, it would also affect the performance due to higher number of network calls.

In the section below we look at these points with an example to figure out how it really works.

How does the pattern work?

Lets say we have a core banking system with so many re-usable service modules. The web app, mobile app, desktop or the ATM, all the clients use these services provided by different modules.

Now lets say we want to expose these services for our ATM client. Out of so many features provided by these modules, our ATM needs only a specific set. Hence, as shown in the figure, we can either let the client access the services directly or use it through a simplified interface.

First of all, with the option-1, the client needs to unnecessarily understand all our internal modules. For example, for getting the approved list of payees for fund transfer purpose, the client has to figure out if it is there in customer profile service or fund transfer service. Both are a close possibility.

Secondly, once the clients figure it out and use it, we can no longer redesign without affecting the clients.

But, a facade can solve both of the above problems for us. With a context specific interface, we reduce the complex system to something which is just enough to meet our ATM client needs. And, since the clients refer only through this interface, we are free to change our internal design as we need.

Source Code for the Demo

Below is the demo code for showing the design and significance of a facade that we have discussed above.

1. The first set has the facade and the related services, showing how does a facade hide the internal design with it’s concise interface.

The inline comments highlights the key points along the code.

package spectutz.dp.struct.facade;
import java.util.List;
import spectutz.dp.struct.facade.services.CustomerProfileService;
import spectutz.dp.struct.facade.services.FundTransferService;
import spectutz.dp.struct.facade.services.SavingsAccountService;
import spectutz.dp.struct.facade.vo.Account;

//We have used minimal code and interfaces to keep the size small and focus on the concept
public class ATMUserServiceFacade implements IATMUserServiceFacade {
	CustomerProfileService customerProfileService = new CustomerProfileService();
	FundTransferService fundTransferService = new FundTransferService();
	SavingsAccountService savingsAccountService = new SavingsAccountService();
	
	//A facade is mostly an indirection that provides 
	//a usage specific simplified view of the underlying complex system. 
	
	@Override
	public boolean withdrawCash(String accountId, float amount) {
		return savingsAccountService.withdrawCash(accountId, amount);
	}
	@Override
	public boolean depositeFunds(String accountId, float amount) {
		return savingsAccountService.depositeFunds(accountId, amount);
	}
	@Override
	public float checkBalance(String accountId) {
		return savingsAccountService.checkBalance(accountId);
	}
	@Override
	public List<Account> getApprovedPayeeList(String accountId) {
		return customerProfileService.getApprovedPayeeList(accountId);
	}
	@Override
	public boolean transferFunds(String fromAccId, String toAccId, float amount) {
		return fundTransferService.transferFunds(fromAccId, toAccId, amount);
	}

}

package spectutz.dp.struct.facade;

import java.util.List;

import spectutz.dp.struct.facade.vo.Account;

//A simple demo facade from ATM user's point of view
public interface IATMUserServiceFacade {
	public boolean withdrawCash(String accountId, float amount);
	public boolean depositeFunds(String accountId, float amount);
	public float checkBalance(String accountId);
	public List<Account> getApprovedPayeeList(String accountId);
	public boolean transferFunds(String fromAccId, String toAccId, float amount);
}

package spectutz.dp.struct.facade.services;
import java.util.ArrayList;
import java.util.List;
import spectutz.dp.struct.facade.vo.Account;

public class CustomerProfileService {
	public List<Account> getApprovedPayeeList(String accountId){
		List<Account> approvedPayees = new ArrayList<Account>();
		approvedPayees.add(new Account("SA4684","Dave Muskan"));
		approvedPayees.add(new Account("SA4684","Tommy Pehelwan"));
		
		System.out.println("Returning approved payee list.");
		return approvedPayees;
	}
}

package spectutz.dp.struct.facade.services;

public class FundTransferService {
	 
	public boolean transferFunds(String fromAccId, String toAccId,float amount) {
		SavingsAccountService savingsAccountService = new SavingsAccountService();
		
		if(savingsAccountService.withdrawCash(fromAccId, amount)) {
			System.out.println("Initiate fund transfer to account id :"+fromAccId);
			return true;
		}else {
			System.out.println("Insufficient balance.");
			return false;
		}		
	}
}

package spectutz.dp.struct.facade.services;

public class SavingsAccountService {
	public boolean withdrawCash(String accountId, float amount) {
		if (checkBalance(accountId) > amount) {
			System.out.println("Amount debited  - " + amount);
			return true; // approved
		} else {
			System.out.println("Not enough balance !");
			return false;// failed
		}
	};

	public float checkBalance(String accountId) {
		return 50000;// dummy amount
	};

	public boolean depositeFunds(String accountId, float amount) {
		System.out.println("Amount desposited :" + amount);
		return true;// successful
	}

}

package spectutz.dp.struct.facade.vo;

public class Account {
	private String id;
	private String name;
	//Other details
	public Account(String id,String name) {
		this.id=id;
		this.name=name;
	}
	public String getId() {
		return id;
	}
	public void setId(String id) {
		this.id = id;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
}

2. This one only has the client code with it’s output, majorly showing the call flow that simplifies the system for the client.

package spectutz.dp.struct.facade;

public class ATMApplicationClientDemo {

	IATMUserServiceFacade atmService = new ATMUserServiceFacade();

	public void withdrawCash(String accountId, float amount) {
		System.out.println("Inside ATMApplicationClientDemo.withdrawCash()");

		boolean isApproved = atmService.withdrawCash(accountId, amount);
		if (isApproved) {
			System.out.println("Disburse the cash.");
		} else {
			System.out.println("Show the error message.");
		}
	}

	public static void main(String[] args) {
		ATMApplicationClientDemo demo = new ATMApplicationClientDemo();

		System.out.println("Call flow : ATM Client --> Facade --> Actual Service\n");
		demo.withdrawCash("SA53762", 2000);
	}
}

//Output showing call flow
/*
Call flow : ATM Client --> Facade --> Actual Service

Inside ATMApplicationClientDemo.withdrawCash()
Inside ATMUserServiceFacade.withdrawCash()
Inside SavingsAccountService.withdrawCash()
Amount debited  - 2000.0
Disburse the cash. 
*/

Comparing with other patterns

1. Facade Vs Adapter :
An adapter looks similar to a facade in terms of design, but they are quite different in their intents.

• A client builds an adapter for addressing the compatibility concerns. Whereas a system builds a facade for providing simpler views to its clients.
• An adapter manages the changes in the underlying system. In contrast, a facade provides the flexibility to re-design the underlying system.

2. Facade Vs Mediator:
A facade may also look similar to behavioral pattern called, the mediator. But, again the way they decouple multiple components from the clients is quite different.

• First of all, a facade simplifies a group of systems whereas a mediator simplifies a group of interactions.
• Second, facade is mostly an indirection to a feature whereas a mediator holds the business logic or a feature.
  • Thus we can think of a facade hiding a group of mediators under it from its clients.
  • For example, the facade talks to FundTransferService which is a mediator that:
    • might be talking to CustomerProfileService for verifying the limits
    • the SavingsAccountService for withdrawal and
    • a third party transfer service for initiating the transfer.

Conclusion

As we have noticed, a facade provides a simplified view irrespective of the underlying design. Its a great way to server multiple user groups from a common set of reusable assets. We use it to serve only that is meaningful and hiding the rest.

In case of microservice environments, integration tools like Apache Camel, API gateways can help us build such facades on top of independent reusable services.

A good builder takes your input the way you understand the object. And, builds the object the way it needs to be built technically. In short, it makes your building process easy irrespective of the underlying complexities !

The Builder is a simple and useful creational pattern to custom build objects and services consisting of multiple parameters.

Comparing it with the factory, the factory has the responsibility of providing the instances of its family of products. But, the builder has the goal to simplify the object building process. Hence, if the underlying products of a factory are complex, we may use a builder to build them.

It’s a widely used pattern to provide a convenient way to build complex components:

• It may be a multi-parameter based service call like a http service call.
• It can be a highly configurable component like a spring boot application.
• Or it might be a multiple-input based complex object structure like a query object.

In all such cases, a builder pattern can provide a simplified and client friendly object building interface. One of the common and simple example in java being the StringBuffer, to append or do other manipulations on multiple strings.

In this article we will first look at why and how to use the builder pattern. And, then follow it up with some real world code snippets to understand its usages better.

Why and How to use the Builder ?

Why should we use it ?

When we design, we do it from a technical point of view keeping the design principle in mind. But, when we use it or write a test case for the system, we hope it were as simple and close to our business requirements. The builder helps us achieve it by bridging the gap. In other words, it provides a business friendly interface, hiding the underlying technical complexities.

Let’s say we want to create usage limits for cards in a banking application. In order to create limits for our multiple usage types, we have a separate UsageLimit object.

Even with this simple object structure, below is the difference in creating the CardUsageLimit for our test cases for instance.

package spectutz.dp.creational.builder.client;

import spectutz.dp.creational.builder.CardUsageLimitBuilder;
import spectutz.dp.creational.builder.UsageLimitBuilder;
import spectutz.dp.creational.builder.card.CardType;
import spectutz.dp.creational.builder.card.CardUsageLimit;
import spectutz.dp.creational.builder.card.UsageType;

public class CardUsageUsingBuilder {
	
	public static void main(String[] args) {
        
		//Build your usage limit the same way as you understand your business
		CardUsageLimit cardUsageLimit = 
				
				new CardUsageLimitBuilder("2334-675-6775", CardType.DEBIT)
				
				.addUsageLimit(new UsageLimitBuilder(UsageType.ATM)
						           .isAllowed(true).setMaxLimit(25000).build())
				.addUsageLimit(new UsageLimitBuilder(UsageType.MERCHANT_OUTLET)
						           .isAllowed(true).setMaxLimit(20000).build())
				.addUsageLimit(new UsageLimitBuilder(UsageType.ONLINE)
						           .isAllowed(false).build())
				.build();

		System.out.println(cardUsageLimit.toString());
		
	}
	
}
// Output 
/*
Card Usage for Card No: 2334-675-6775 AND Card Type : DEBIT

Card Usage Limits :
Usage Type: ATM; Is Allowed: true; Max Limit: 25000
Usage Type: ONLINE; Is Allowed: false; Max Limit: 0
Usage Type: MERCHANT_OUTLET; Is Allowed: true; Max Limit: 20000
*/

package spectutz.dp.creational.builder.client;

import spectutz.dp.creational.builder.card.CardType;
import spectutz.dp.creational.builder.card.CardUsageLimit;
import spectutz.dp.creational.builder.card.UsageLimit;
import spectutz.dp.creational.builder.card.UsageType;

public class CardUsageWithoutBuilder {
	
	public static void main(String[] args) {
		
		//Build your usage limit as per your underlying data structure
		CardUsageLimit cardUsageLimit = new CardUsageLimit();
		cardUsageLimit.setCardNumber("2334-675-6775");
		cardUsageLimit.setCardType(CardType.DEBIT);
		
		UsageLimit atmUsageLimit = new UsageLimit();
		atmUsageLimit.setUsageType(UsageType.ATM);
		atmUsageLimit.setAllowedFlag(true);
		atmUsageLimit.setMaxLimit(25000);
		
		UsageLimit merChantOutLetUsageLimit = new UsageLimit();
		merChantOutLetUsageLimit.setUsageType(UsageType.MERCHANT_OUTLET);
		merChantOutLetUsageLimit.setAllowedFlag(true);
		merChantOutLetUsageLimit.setMaxLimit(20000);
		
		UsageLimit onlineUsageLimit = new UsageLimit();
		onlineUsageLimit.setUsageType(UsageType.ONLINE);
		onlineUsageLimit.setAllowedFlag(false);
		
		cardUsageLimit.addUsageLimit(atmUsageLimit);
		cardUsageLimit.addUsageLimit(merChantOutLetUsageLimit);
		cardUsageLimit.addUsageLimit(onlineUsageLimit);

		System.out.println(cardUsageLimit);
	}
	
}

// Output 
/*
Card Usage for Card No: 2334-675-6775 AND Card Type : DEBIT

Card Usage Limits :
Usage Type: ATM; Is Allowed: true; Max Limit: 25000
Usage Type: ONLINE; Is Allowed: false; Max Limit: 0
Usage Type: MERCHANT_OUTLET; Is Allowed: true; Max Limit: 20000
*/

In the above example, we can clearly figure out how a builder makes our client interface compact and much more readable. Moreover, it keeps the client interface independent of the underlying data structure.

How does it work ?

A builder pattern basically consists of two different types of APIs :

1. Fluent and Business Friendly APIs to Collect a Series of Inputs :
   • Regardless of the underlying data structure, we can design these apis in a business friendly manner.
     • The fluent apis makes the builder code highly readable.
   • For example, even for complex queries and expression objects these apis can still look non-technical.
2. A Build API to Create and Return the Desired Object :
   • This is where we do the final processing, if any, to build and return the desired object.

With the client code shown above, below are the objects and their builders for the card usage example.

package spectutz.dp.creational.builder;

import spectutz.dp.creational.builder.card.CardType;
import spectutz.dp.creational.builder.card.CardUsageLimit;
import spectutz.dp.creational.builder.card.UsageLimit;

public class CardUsageLimitBuilder {
	
    CardUsageLimit cardUsageLimit;	

    public CardUsageLimitBuilder(String cardNumber, CardType cardType){
    	cardUsageLimit = new CardUsageLimit();
    	cardUsageLimit.setCardNumber(cardNumber);
    	cardUsageLimit.setCardType(cardType);
    }
    public CardUsageLimitBuilder addUsageLimit(UsageLimit usageLimit){
    	cardUsageLimit.addUsageLimit(usageLimit); 
    	return this;
    }
    
    public CardUsageLimit build() {
    	return cardUsageLimit;	
    }
    
}

package spectutz.dp.creational.builder;

import spectutz.dp.creational.builder.card.UsageLimit;
import spectutz.dp.creational.builder.card.UsageType;

public class UsageLimitBuilder {
	
    UsageLimit usageLimit;	

    public UsageLimitBuilder(UsageType usageType){
    	this.usageLimit = new UsageLimit();
    	usageLimit.setUsageType(usageType);
    }
    
    public UsageLimitBuilder isAllowed(boolean isAllowed){
    	usageLimit.setAllowedFlag(isAllowed);
    	return this;
    }
    public UsageLimitBuilder setMaxLimit(int maxLimit){
    	usageLimit.setMaxLimit(maxLimit);
    	return this;
    }
    public UsageLimit build(){
    	return usageLimit;
    }
    
}

package spectutz.dp.creational.builder.card;

import java.util.HashMap;
import java.util.Map;

public class CardUsageLimit {	
	private String cardNumber;
	private CardType cardType;
    private Map<UsageType, UsageLimit> usageLimits = new HashMap<UsageType, UsageLimit>();
    
	public String getCardNumber() {
		return cardNumber;
	}
	public void setCardNumber(String cardNumber) {
		this.cardNumber = cardNumber;
	}
	public CardType getCardType() {
		return cardType;
	}
	public void setCardType(CardType cardType) {
		this.cardType = cardType;
	}
	public Map<UsageType, UsageLimit> getUsageLimits() {
		return usageLimits;
	}
	public void addUsageLimit(UsageLimit usageLimit) {
		this.usageLimits.put(usageLimit.getUsageType(), usageLimit);
	}
	
	public String toString() {
		StringBuffer cardUsageLimit = new StringBuffer("Card Usage for Card No: "+this.cardNumber);
		cardUsageLimit.append(" AND Card Type : "+this.cardType)
		.append("\n\nCard Usage Limits :");
		
		usageLimits.forEach((k, v) -> {
			cardUsageLimit.append("\nUsage Type: " + k )
			.append("; Is Allowed: " + v.isAllowed())
			.append("; Max Limit: " + v.getMaxLimit());
		});
		
		return cardUsageLimit.toString();
	}
}

package spectutz.dp.creational.builder.card;

public class UsageLimit {
	
	private UsageType usageType;
	private boolean isAllowed;
	private int maxLimit;
	
	public UsageType getUsageType() {
		return usageType;
	}
	public void setUsageType(UsageType usageType) {
		this.usageType = usageType;
	}
	public boolean isAllowed() {
		return isAllowed;
	}
	public void setAllowedFlag(boolean isAllowed) {
		this.isAllowed = isAllowed;
	}
	public int getMaxLimit() {
		return maxLimit;
	}
	public void setMaxLimit(int maxLimit) {
		this.maxLimit = maxLimit;
	}
	

}

package spectutz.dp.creational.builder.card;

public enum CardType {	
	DEBIT, CREDIT;
}

package spectutz.dp.creational.builder.card;

public enum UsageType {	
	ATM, MERCHANT_OUTLET, ONLINE;
}

Some Realtime Usages

Use Case -1

The below is a sample code for creating an EhCache(2.8 version) which is a highly customizable component. By default, it comes with lots of default configurations but, it lets us customize many of them through CacheConfiguration.

Here, the CacheConfiguration uses the builder pattern. And, as we can see, the pattern makes it fluent and flexible to add our custom options.

//Create a singleton CacheManager using defaults
CacheManager manager = CacheManager.create();

// CacheConfiguration : Update as many configs as you want where the rest will run with the defaults.
Cache sampleCache= new Cache(
  new CacheConfiguration("sampleCache", maxEntriesLocalHeap)
    .memoryStoreEvictionPolicy(MemoryStoreEvictionPolicy.LFU)
    .eternal(false)
    .timeToLiveSeconds(60)
    .timeToIdleSeconds(30)
    .diskExpiryThreadIntervalSeconds(0)
    .persistence(new PersistenceConfiguration().strategy(Strategy.LOCALTEMPSWAP)));

  manager.addCache(sampleCache);

Use Case-2

A Builder can hide a lot of complexities from you.

In case of stuffs like hibernate queries or elastic search queries, building the desired outcome manually will be lot difficult.

Here, the builder takes our input using a simpler, business friendly interface. Then, it collects them into a technically suitable intermediate object. Finally, it uses the intermediate object to produce our desired output. Moreover, sometimes we may need the output in multiple formats. The hibernate queries supporting multiple databases for instance.

Below is an example to build a search query to find laptops with RAM greater than 8GB and screen size between 15-15.9 inch.

The two tabs below show, how we build vs what we need. The difference in their complexities shows the beauty of the builder pattern.

		BoolQueryBuilder boolQuery = QueryBuilders.boolQuery()
				.must(QueryBuilders.termQuery("product-category", "laptop")) 
				.must(QueryBuilders.termQuery("RAM-GB", "4")) 
				.must(QueryBuilders.rangeQuery("screen-size").gte(15).lte(15.9)); 
		
		
		System.out.println(boolQuery.toString());

{
  "bool" : {
    "must" : [
      {
        "term" : {
          "product-category" : {
            "value" : "laptop",
            "boost" : 1.0
          }
        }
      },
      {
        "term" : {
          "RAM-GB" : {
            "value" : "4",
            "boost" : 1.0
          }
        }
      },
      {
        "range" : {
          "screen-size" : {
            "from" : 15,
            "to" : 15.9,
            "include_lower" : true,
            "include_upper" : true,
            "boost" : 1.0
          }
        }
      }
    ],
    "adjust_pure_negative" : true,
    "boost" : 1.0
  }
}

Conclusion

To summarize what we have seen above, the builder is a quite an useful design pattern to make our life easy. It helps us hide the unavoidable technical complexities from the end users. Irrespective of the underlying complexities, the builder can collect the inputs in a much more compact and readable format.

An Abstract Factory provides a set of Factories at one place
because we love to use their products together!

An Abstract Factory lets us group a related set of product families(or factories) based on our usage pattern.

It may directly instantiate the products or may source them from their respective product factories. And, like a factory, it exposes abstract products to its clients, so that they can replace them with appropriate concrete versions at runtime.

Whereas a factory creates products belonging to single family; an abstract factory provide a meaningful sets of these products from different families from a single interface.

Examples in Brief

Let us look at couple of examples in brief, in order to understand the grouping better. Later we will discuss on these in more detail for clarifying it further.

Example 1 : Lets say we have loan processing application where each loan type has its own processor, pre-processor, validator etc.

So, ideally we will have separate factories for these components. But, since we use them together, how about providing a single interface to our clients for creating these components ? This is where the abstract factory comes in handy.

Example 2 : Lets say we are creating a PC health analyzer module for multiple platforms. Even though we need platform specific analyzers, installation on any platform needs access to only its own set of analyzers. So, how can we group these platform specific analyzers and filter out the unnecessary ones ?

How does the pattern work?

In this part we will restrict our discussions only to the above two examples. But, we will analyze them with diagrams and code samples, so as to understand how the pattern works and its benefits.

Example -1

Lets say we have a loan processing application where we have many similar components like a processor, pre-processor, validator for each of the loan types. Hence, instead of getting these components from so many factories, we may need a single interface that provides each of these required components.

As in option-1, we can build an abstract factory that composes all the abstract version of our product set. Then, build loan specific concrete factories that returns the concrete products, specific to the loan type. For example, the ‘HomeLoanFactory’ will return the processors and the validators specific to the home loan as shown.

But, we have so many loan types and many more are going to be added. Hence, the challenge is that we will end up with lot many concrete factories. Therefore, to retain the benefits without the challenge, we can go with option-2.

In option-2, we have simply added the loan type as a parameter to the factory methods, to avoid creating multiple classes. But, the underlying concept of grouping products from different factories for our business cases remains the same.

Having seen this, we will see when will the option-1 be useful in our other example. But, before that here are the code for this demo example.

The first set shows how our abstract factory, UnifiedLoanFactory works and makes use of the other factories. And, the second set lists the related abstract and the concrete products.

package spectutz.dp.creational.absfactory.loan;

import spectutz.dp.creational.absfactory.loan.processor.ILoanProcessor;
import spectutz.dp.creational.absfactory.loan.processor.LoanProcessorFactory;
import spectutz.dp.creational.absfactory.loan.validator.ILoanValidator;
import spectutz.dp.creational.absfactory.loan.validator.LoanValidatorFactory;
import spectutz.dp.creational.factory.loan.vo.LoanType;

public class UnifiedLoanFactory{
	private static UnifiedLoanFactory unifiedLoanFactory = new UnifiedLoanFactory();
	
	private UnifiedLoanFactory() {}
	public static UnifiedLoanFactory getInstance() {
		return unifiedLoanFactory;
	}
	
	// *** Abstract Factory : Uses the respective factories to retrieve the products! ***//
	
	public ILoanProcessor getLoanProcessor(LoanType loanType){	
		return LoanProcessorFactory.getInstance().getLoanProcessor(loanType);
	}
	public ILoanValidator getLoanValidator(LoanType loanType){	
		return LoanValidatorFactory.getInstance().getLoanValidator(loanType);
	}
}

package spectutz.dp.creational.absfactory.loan.validator;

import java.util.HashMap;
import java.util.Map;

import spectutz.dp.creational.absfactory.loan.vo.LoanType;

public class LoanValidatorFactory {
	private static LoanValidatorFactory instance = new LoanValidatorFactory();
	private static Map<LoanType, ILoanValidator> registry;
	
	static {
		registry = new HashMap<LoanType, ILoanValidator>();
		registry.put(LoanType.HOME_LOAN, new HomeLoanValidator());
		registry.put(LoanType.PERSONAL_LOAN, new PersonalLoanValidator());
		registry.put(LoanType.CAR_LOAN, new CarLoanValidator());
		//For any new loan processor - Add them to this registry !
	}
	
	public ILoanValidator getLoanValidator(LoanType loanType) {//throws Exception{		
		return registry.get(loanType);		
	}
	
	public static LoanValidatorFactory getInstance() {
		return instance;
	}
}

package spectutz.dp.creational.absfactory.loan.processor;

import java.util.HashMap;
import java.util.Map;

import spectutz.dp.creational.absfactory.loan.vo.LoanType;

public class LoanProcessorFactory {
	private static LoanProcessorFactory instance = new LoanProcessorFactory();
	private static Map<LoanType, ILoanProcessor> registry;
	
	static {
		registry = new HashMap<LoanType, ILoanProcessor>();
		registry.put(LoanType.HOME_LOAN, new HomeLoanProcessor());
		registry.put(LoanType.PERSONAL_LOAN, new PersonalLoanProcessor());
		registry.put(LoanType.CAR_LOAN, new CarLoanProcessor());
		//For any new loan processor - Add them to this registry !
	}
	
	public ILoanProcessor getLoanProcessor(LoanType loanType) {		
		return registry.get(loanType);		
	}
	
	public static LoanProcessorFactory getInstance() {
		return instance;
	}
}

package spectutz.dp.creational.absfactory.loan;

import spectutz.dp.creational.absfactory.loan.processor.ILoanProcessor;
import spectutz.dp.creational.absfactory.loan.processor.LoanProcessorFactory;
import spectutz.dp.creational.absfactory.loan.validator.ILoanValidator;
import spectutz.dp.creational.absfactory.loan.validator.LoanValidatorFactory;
import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;
import spectutz.dp.creational.absfactory.loan.vo.LoanType;

public class WithAndWithoutAbstractFactoryDemo {
	
	public static void main(String[] args) {
		LoanApplication loanApplication = new LoanApplication();
		loanApplication.setLoanType(LoanType.PERSONAL_LOAN);
		
		WithAndWithoutAbstractFactoryDemo demoClient = new WithAndWithoutAbstractFactoryDemo();
		demoClient.processLoanWithAbstractFactory(loanApplication);
		demoClient.processLoanWithoutAbstractFactory(loanApplication);
		
	}
	
    public void processLoanWithAbstractFactory(LoanApplication loanApplication) {
    	LoanType loanType = loanApplication.getLoanType();

    	//Get all products from a single interface..
    	UnifiedLoanFactory unifiedLoanFactory = UnifiedLoanFactory.getInstance();    	
    	ILoanValidator loanValidator = unifiedLoanFactory.getLoanValidator(loanType);
    	ILoanProcessor loanProcessor = unifiedLoanFactory.getLoanProcessor(loanType);
    	
    	if(loanValidator.validate(loanApplication)) {
    		loanProcessor.process(loanApplication);
    	}else {
    		//throw exception with validation errors
    	}
    }
    
    public void processLoanWithoutAbstractFactory(LoanApplication loanApplication) {
    	System.out.println("\n Start : processLoanWithFactory.....");
    	LoanType loanType = loanApplication.getLoanType();
    	
    	//Get the  products from its respective factories..
    	ILoanValidator loanValidator = LoanValidatorFactory.getInstance()
    									.getLoanValidator(loanType);
    	ILoanProcessor loanProcessor = LoanProcessorFactory.getInstance()
    									.getLoanProcessor(loanType);
    	
    	if(loanValidator.validate(loanApplication)) {
    		loanProcessor.process(loanApplication);
    	}else {
    		//throw exception with validation errors
    	}
    }
}

The code for the abstract and concrete products in the demo for our reference.

package spectutz.dp.creational.absfactory.loan.validator;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public interface ILoanValidator {
	
	public boolean validate(LoanApplication loanApplication);

}

package spectutz.dp.creational.absfactory.loan.validator;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public class HomeLoanValidator implements ILoanValidator{

	@Override
	public boolean validate(LoanApplication loanApplication) {
		System.out.println("Validate the home loan");
		return true; //validated successfully
	}
	
}

package spectutz.dp.creational.absfactory.loan.validator;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public class PersonalLoanValidator implements ILoanValidator{

	@Override
	public boolean validate(LoanApplication loanApplication) {
		System.out.println("Validate personal loan");
		return true; //validated successfully
	}
}

package spectutz.dp.creational.absfactory.loan.validator;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public class CarLoanValidator implements ILoanValidator{

	@Override
	public boolean validate(LoanApplication loanApplication) {
		System.out.println("Validate the car loan");
		return true; //validated successfully
	}

}

package spectutz.dp.creational.absfactory.loan.processor;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public interface ILoanProcessor {
	
	public void process(LoanApplication loanApplication);

}

package spectutz.dp.creational.absfactory.loan.processor;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public class HomeLoanProcessor implements ILoanProcessor{

	@Override
	public void process(LoanApplication loanApplication) {
		System.out.println("Process the home loan");		
	}
	
}

package spectutz.dp.creational.absfactory.loan.processor;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public class PersonalLoanProcessor implements ILoanProcessor{

	@Override
	public void process(LoanApplication loanApplication) {
		System.out.println("Process the personal loan");		
	}
}

package spectutz.dp.creational.absfactory.loan.processor;

import spectutz.dp.creational.absfactory.loan.vo.LoanApplication;

public class CarLoanProcessor implements ILoanProcessor{

	@Override
	public void process(LoanApplication loanApplication) {
		System.out.println("Process the car loan");
		
	}

}

package spectutz.dp.creational.absfactory.loan.vo;


public enum LoanType {
   HOME_LOAN, PERSONAL_LOAN, CAR_LOAN   
}

package spectutz.dp.creational.absfactory.loan.vo;

public class LoanApplication {
	LoanType loanType;

	public LoanType getLoanType() {
		return loanType;
	}

	public void setLoanType(LoanType loanType) {
		this.loanType = loanType;
	}
}

Example -2

Lets say we are developing a PC health analyzer module supporting multiple platforms.

Since each platform provides its own APIs to retrieve its component information, we need platform specific analyzers as shown below.

However, when we install this module, we only need the analyzers specific to that platform. Hence, creating a generic implementation, as in option-2 in example-1, does not make sense.

That’s why the option-1 is better as it provides only the platform specific products. Additionally, it also does not provide access to wrongfully use the analyzers meant for other platforms. For example, on a Mac system we will use ‘MacHealthAnalyzer’. And, as shown in the diagram, it will include the set of analyzers specific to Mac alone.

Moreover, since we are analyzing similar components, the ‘AbstractHealthAnalyzer’ standardizes the analyzer set for all platforms.

Conclusion

An abstract factory is an useful pattern to group the products together based on our usage pattern. Like factories, it keeps the client loosely coupled with the products it uses.

When our use case involves multiple factories, an abstract factory can consolidate them into a single interface.

Moreover, like in example-2 above, it can also help us build platform or product variant specific, component sets.

A Factory produces a family of products for us
so that we can easily order them for our use just by its tagged name .

The Factory is one of the most widely used creational design pattern. It hides the creation of a family of products, so that we can dynamically choose them for our usage just using a mapped name or a simple set of identifiers.

Benefits of using Factory Pattern

First of all, by hiding the creational logic, it simplifies the dependency for its clients. In other words, the clients can simply depend on a base class to use a long list of its sub-classes.

Secondly, a factory also helps us generalize our usage logic. Thus, making our design open for extension, but closed for modification.

Moreover, in case of invariant(client/context independent) instances, a factory can cache & share a single instance. Hence, a factory can also optimize the instance lifecycle and make our application light weight. We will discuss more on this in the Flyweight design pattern.

We will look at all these points in more detail with diagrams and code snippets in the sections below. Let’s start with exploring how the factory works.

How does the pattern work?

Let’s say we are developing a loan processing module where each loan type has a different processor. The below diagram shows how can we use a factory to simplify dependencies and generalize the processing logic.

The key point to note in the above diagram are :

1. Deferred Instantiation for Decoupling the Products

Here we have a family of loan processors but, the client only needs to know their base type i.e. ILoanProcessor.

By deferring the instantiation, the factory allows us to dynamically choose a product to replace our base product. Moreover, the factory only needs a simple identifier to decide on the actual product.

Thus, a factory greatly reduces the dependencies for its clients. In fact, it shifts the dependencies on a family of products from the clients to itself.

As regards the identities, we have mapped processors one to one with their loan types. In case the products are complex, we may need a multiple set of parameters to identify and create their instances.

public class LoanProcessorFactory {
        //Other code...
	private static Map<LoanType, LoanProcessor> registry;
	
	static {
		registry = new HashMap<LoanType, LoanProcessor>();
		registry.put(LoanType.NEW_HOME, new HomeLoanProcessor());
		registry.put(LoanType.HOME_RENOVATION, new HomeRenovationLoanProcessor());
		registry.put(LoanType.HOME_CONSTRUCTION, new HomeConstructionLoanProcessor());
		//For any new loan processor - Add them to this registry !
	}
	
	public LoanProcessor getLoanProcessor(LoanType loanType) {//throws Exception{		
		return registry.get(loanType);		
	}
        //Other code...	
}

2. Factory Helps us Generalize our Code

The two loan processing methods shows the difference in processing logic with and without using a factory. It clearly shows how a factory makes our processing logic generic and flexible.

For instance, for a new loan type we simply have to register the instance of the new processor in the factory. There is no need to modify the processing logic inside the clients.

public class WithAndWithoutFactoryDemo {
	//Other code ........
	
    public void processLoanWithoutFactory(LoanApplication loanApplication) {
    	System.out.println("\n Start : processLoanWithoutFactory.....");
    	if(LoanType.NEW_HOME == loanApplication.getLoanType()) {
    		new HomeLoanProcessor().process(loanApplication);
    	} else if(LoanType.HOME_RENOVATION == loanApplication.getLoanType()) {
    		new HomeRenovationLoanProcessor().process(loanApplication);
    	} else if(LoanType.HOME_CONSTRUCTION == loanApplication.getLoanType()) {
    		new HomeRenovationLoanProcessor().process(loanApplication);
    	}
    	//Keep adding the conditional blocks for each new loan here........
    }
    
    public void processLoanWithFactory(LoanApplication loanApplication) {
    	System.out.println("\n Start : processLoanWithFactory.....");
    	//The client code is dependent only on base loan processor...
    	LoanProcessor loanProcessor = LoanProcessorFactory.getInstance()
    								  .getLoanProcessor(loanApplication.getLoanType());
    	
    	//The logic is generic - Simply register the new processor instance in the factory! 
    	loanProcessor.process(loanApplication);
    }
}

3. Factory can Optimize the Instance Management

Since a factory centrally controls the instantiation process, it allows us to instantiate once and then re-use the instances. This reusability is not only across classes but, also across the user requests.

Again, reusing the instances is absolutely fine when we are dealing with invariant(client\context independent) beans, as we have used in our example. But, just in case we need client specific instances, we can always create them on every request.

public class LoanProcessorFactory {
	private static LoanProcessorFactory instance = new LoanProcessorFactory();
	private static Map<LoanType, LoanProcessor> registry;
	
	static {//Create the instances once and save it for re-use  
		registry = new HashMap<LoanType, LoanProcessor>();
		registry.put(LoanType.NEW_HOME, new HomeLoanProcessor());
		registry.put(LoanType.HOME_RENOVATION, new HomeRenovationLoanProcessor());
		registry.put(LoanType.HOME_CONSTRUCTION, new HomeConstructionLoanProcessor());
	}
	
	//Serve the saved instances.....		
	public LoanProcessor getLoanProcessor(LoanType loanType) {//throws Exception{		
		return registry.get(loanType);		
	}
	
	public static LoanProcessorFactory getInstance() {
		return instance;
	}
}

Source Code for the Demo

Below are the source code for the demo example we have discussed above.

This first set shows the Factory and the client code showing its usage.

package spectutz.dp.creational.factory.loan.processor;

import java.util.HashMap;
import java.util.Map;

import spectutz.dp.creational.factory.loan.vo.LoanType;

public class LoanProcessorFactory {
	private static LoanProcessorFactory instance = new LoanProcessorFactory();
	private static Map<LoanType, LoanProcessor> registry;
	
	static {
		registry = new HashMap<LoanType, LoanProcessor>();
		registry.put(LoanType.NEW_HOME, new HomeLoanProcessor());
		registry.put(LoanType.HOME_RENOVATION, new HomeRenovationLoanProcessor());
		registry.put(LoanType.HOME_CONSTRUCTION, new HomeConstructionLoanProcessor());
		//For any new loan processor - Add them to this registry !
	}
	
	public LoanProcessor getLoanProcessor(LoanType loanType) {//throws Exception{		
		return registry.get(loanType);		
	}
	
	public static LoanProcessorFactory getInstance() {
		return instance;
	}
}

package spectutz.dp.creational.factory.loan;

import spectutz.dp.creational.factory.loan.processor.HomeLoanProcessor;
import spectutz.dp.creational.factory.loan.processor.HomeRenovationLoanProcessor;
import spectutz.dp.creational.factory.loan.processor.LoanProcessor;
import spectutz.dp.creational.factory.loan.processor.LoanProcessorFactory;
import spectutz.dp.creational.factory.loan.vo.LoanApplication;
import spectutz.dp.creational.factory.loan.vo.LoanType;

public class WithAndWithoutFactoryDemo {
	
	public static void main(String[] args) {
		LoanApplication loanApplication = new LoanApplication();
		loanApplication.setLoanType(LoanType.HOME_RENOVATION);
		
		WithAndWithoutFactoryDemo demoClient = new WithAndWithoutFactoryDemo();
		demoClient.processLoanWithoutFactory(loanApplication);
		demoClient.processLoanWithFactory(loanApplication);
		
	}
	
    public void processLoanWithoutFactory(LoanApplication loanApplication) {
    	System.out.println("\n Start : processLoanWithoutFactory.....");
    	if(LoanType.NEW_HOME == loanApplication.getLoanType()) {
    		new HomeLoanProcessor().process(loanApplication);
    	} else if(LoanType.HOME_RENOVATION == loanApplication.getLoanType()) {
    		new HomeRenovationLoanProcessor().process(loanApplication);
    	} else if(LoanType.HOME_CONSTRUCTION == loanApplication.getLoanType()) {
    		new HomeRenovationLoanProcessor().process(loanApplication);
    	}
    	//Add the logic for new loans here........
    }
    
    public void processLoanWithFactory(LoanApplication loanApplication) {
    	System.out.println("\n Start : processLoanWithFactory.....");
    	LoanProcessor loanProcessor = LoanProcessorFactory.getInstance()
    								  .getLoanProcessor(loanApplication.getLoanType());
    	
    	//The logic is generic - Simply add the new processor in the factory! 
    	loanProcessor.process(loanApplication);
    }

}

This second set includes the product family of loan processors and the loan object.

package spectutz.dp.creational.factory.loan.processor;

import spectutz.dp.creational.factory.loan.vo.LoanApplication;

public class HomeLoanProcessor implements LoanProcessor{

	@Override
	public void process(LoanApplication loanApplication) {
		System.out.println("Process Home Loan");		
	}
	
}

package spectutz.dp.creational.factory.loan.processor;

import spectutz.dp.creational.factory.loan.vo.LoanApplication;

public class HomeRenovationLoanProcessor implements LoanProcessor{

	@Override
	public void process(LoanApplication loanApplication) {
		System.out.println("Process Home Renovation Loan");		
	}
}

package spectutz.dp.creational.factory.loan.processor;

import spectutz.dp.creational.factory.loan.vo.LoanApplication;

public class HomeConstructionLoanProcessor implements LoanProcessor{

	@Override
	public void process(LoanApplication loanApplication) {
		System.out.println("Process Home Construction Loan");		
	}
}

package spectutz.dp.creational.factory.loan.processor;

import spectutz.dp.creational.factory.loan.vo.LoanApplication;

public interface LoanProcessor {
	
	public void process(LoanApplication loanApplication);

}

package spectutz.dp.creational.factory.loan.vo;

public class LoanApplication {
	LoanType loanType;

	public LoanType getLoanType() {
		return loanType;
	}

	public void setLoanType(LoanType loanType) {
		this.loanType = loanType;
	}
}

package spectutz.dp.creational.factory.loan.vo;


public enum LoanType {
   NEW_HOME, HOME_CONSTRUCTION, HOME_RENOVATION   
}

Conclusion

To summaries, the factory is quite an useful pattern for managing the instances when we have a family of products. It helps us generalize the processing logic. Thus, allowing us to extend our deign with new specific products without affecting the core logic.

Moreover, it lets us re-use the product instances, helping us to make our application light weight.