The Factory method pattern defines an interface in terms of contract for creating an object but let’s subclasses decide which classes to instantiate. Factory method lets the class differ instantiation to sub classes. It says that when you are about to instantiate let’s encapsulate that instantiation so that we can make it uniform across all places so that you can use the factory whenever you want to instantiate, and the factory is responsible for instantiating.
It might be seeming silly to keep a wrapper on the keyword new. But the benefit is instantiation can be complex and you don’t want this creational logic of object to be present in multiple places in the code and the other benefit we get using factory pattern is polymorphism at run time you can just swap one instance class to the other.
Example
Consider an example where we have three classes A, B, C implementing an interface. Let’s say at some point of code we need to instantiate A, B or C based on the business logic and we don’t know up to that point which class we are going to need and if we have the same creational logic at multiple places in the code leads to duplication. By implementing factory pattern, we can eliminate the duplication and encapsulate the creational logic to one place.
For example, if the business logic was to randomly create either A, B or C, and we have a case statement for selecting one of random instances and we do that several place in the code. Also let’s suppose random generator is not the only creation business logic we have but we also have some other creational mechanism for creating the instances. It becomes complex when these multiple creational mechanisms are scattered across the project. Factories are responsible for handling this creation of the objects.
Code
Below code shows an example where two credit unions merge, and they share an API that pulls account information from each company that merged. The credit unions are Citi Credit Union and the other National Credit Union. It uses factory pattern to return the savings account object based on the account number passed in.
UML Diagram
Below UML diagram shows Dog, Cat & Duck derived classes implementing the Animal interface. We have RandomFactroy which creates these Animals. When we call CreateAnimal on RandomFactory we get back Animal and we don’t know if the Animal is Cat, Dog or a Duck. The other Factory we have is a BalancedFactory which does the same thing of returning the Animal but having different business logic from RandomFactory. Let’s say The Balanced Factory has State and upon third creation we have equal number of instances of three different types of Animals. These two Factory classes implement the AnimalFactory base class and provides their own implementation of creating Animals.
Generalized UML Diagram
The below UML diagram is a generalized way to represent Factory pattern. If we compare this to our example which we looked at before we can compare Product to Animal, Creator to AnimalFactory, Concrete Creators are RandomFactory and BalancedFactory. Concrete Products are Dog, Cat & Duck.
If we just have only one creator or factory method for creating the products, we call that pattern to be Simple Factory.
GitHub Link: FactoryPattern
#11DayOf100DaysOfCode
Comments