Factory and Abstract Factory Pattern in Apex

by - 1:56 AM

While building solution over force.com platform, you can easily observe MVC pattern across the platform, but when you scale to enterprise level solution, design pattern you chose, on top of MVC play a key role in putting direction the custom development and specially designing enterprise level of services. There are common design patterns and associated best practices for Apex Developer and how can you leverage those patterns.

I recommend reading common apex pattern here in official podium. So lets talk about common and most use designed pattern (factory) pattern, I already have written an example here on this. But over the period of time, I learned there is low understanding among peers on Factory Pattern and Abstract Factory Pattern.  Lets go in detail on the pattern with their class diagram for proper understanding on this

Supported Keywords in Apex 

Factory pattern

Factory pattern is a creational pattern (meaning it will deal with creation of objects). A creation pattern abstracts the object creation or instantiation of objects by hiding how the objects are created and in turn offer independency on object creation process. On the other hand, an Abstract Factory Pattern adds another level of abstraction little higher than factory pattern, and in-turn return Factory classes.

Scenario : Imagine writing a custom application, when you want the end-user to record a machine install on client location. This machine can be installed on-site or could be a remote install. In both the case install() is the common method on each type of install. Below is the UML diagram to add clarity on this.

Abstract Factory pattern

An Abstract factory pattern is one level of abstraction higher than a factory method pattern, which means the abstract factory returns the appropriate factory classes, which will later on return one of the product subclasses. Let’s look at a code now

When to use Factory and Abstract Factory Pattern ?

Factory pattern returns an instance of several (product hierarchy) subclasses (like Onsite, Remote etc), but the calling code is unaware of the actual implementation class.

The calling code invokes the method on the interface for example Install and using polymorphism the correct getInstall() method gets invoked. So, as you can see, the factory pattern reduces the coupling or the dependencies between the calling code and called objects like Onsite, Remote etc. This is a very powerful and common feature in many frameworks.

You do not have to create a new Onsite or a new Remote on each invocation as shown in the sample code, which is for the purpose of illustration and simplicity.

Another benefit going for the factory is that unlike calling constructors directly, factory patterns have more meaningful names like getInstall(...), getInstance(...) etc, which may make calling code more clear.

Using Singleton Pattern in Factory Pattern

Another important aspect to consider when writing your factory class is that, it does not make sense to create a new factory object for each invocation as it is shown in the sample code, which is just fine for the illustration purpose.

InstallFactory factory = new SimpleInstallFactory();

To overcome this, you can incorporate the singleton design pattern into your factory pattern code. The singleton design pattern will create only a single instance of your SimpleInstallFactory class.

Since an abstract factory pattern is unlike factory pattern, where you need to have an instance for each of the two factories (i.e. SimpleInstallFactory and ComplexInstallFactory) returned, you can still incorporate the singleton pattern as an access point and have an instance of a HashMap, store your instances of both factories.

What is Singleton Pattern? 

A singleton is a class that can be instantiated only one time. Repeated calls always return the same instance. Ensures that a class has only one instance, and provide a global point of access.

You May Also Like