Factory Design Pattern
Factory, as the name suggests, is a place which produces some kind of products. In Object-Oriented Programming, a factory design pattern is a type of Creational pattern that provides us with a way to create objects without exposing the creation logic to the clients and using a common interface to refer to those objects.
Let’s start with the question of why do we need to use the Factory Design pattern?
Scenario 1:
Imagine a scenario where the object creation logic change, that is, we anticipate that there could be a change in the strategy for the construction of the object in the future.
Scenario 2:
What if we need to decide the kind of object we want at runtime?
In Scenario 1 if we do not externalize our object creation policy then we would violate the Open-Close Principle. This is because if the logic of object creation changes then we would need to modify this class.
In Scenario 2, since we need to decide the kind of object we want at runtime, if we incorporate the logic of Object creation in the same class, then we would in violation of the Single Responsibility Principle as our class is handling its own logic as well as the object creation logic of other classes.
Both of the above scenarios will also force us to violate an important design Principle where we encapsulate whatever code varies.
To tackle this, we would be using Factory Design Pattern.
Let’s understand this better with help of a Problematic example followed up by a correct example demonstrating the use of Factory Pattern.
Let’s suppose that we have our own transport company in which we transport items with the help of our truck. The Program will roughly translate to this:
In the above snippet, we define a class called Truck where we define three methods namely pickup, travel and deliver.
In the above snippet, we have a class in which we define a method called transport which is responsible for transporting the items from one location to another. As observed it calls the methods of Truck class which we created.
Now, what if we one day decide to support transportation by Flight too? Or Freight, Ship also? In that case, we need to change our Transport class completely. What if the user of the program is to decide which Transportation mode to use? In any of these use cases, we will be needing to modify the Transport class.
This is ok to get our code working but it will violate the Open-Closed principle.
To overcome that we will now use the factory pattern.
The above interface has three methods which will be defined by individual Transporation Mode classes such as Truck, Flight etc.
The above class Truck implements the ITransportMode interface and override its method with its own implementation.
The above class Flight implements the ITransportMode interface and override its method with its own implementation.
The above class is called Transport Class, can also be called a Creator Class. The creator class handles some other responsibility also along with the creation of the Object(delegated to its subclasses). The creator class has two methods namely transport and getTransportInstance( which is an abstract method).
The transport method makes a call to the getTransportInstance which is an abstract method. This method is responsible for returning an object of type ITransportMode. The method will be overridden by individual factory classes supplying the desired object.
In the above snippet, the TruckFactory class overrides the getTransportInstance to return the object of the Truck class.
Similarly, the FlightFactory class overrides the getTransportInstance to return the object of the Flight class.
Finally, in our driver class, we instantiate the Transport object with the TruckFactory type or FlightFactory type.
The advantage of this approach is that if in the future a new mode of Transportation comes then we just need to define a factory for it and create a new subclass implementing the common interface which all the Products use. This makes our code very flexible to any change
We could have also shifted the object creation logic to a method instead of a class. In the method, we would have some switch cases where we decide which object to create. This would be useful if the object creation policy is a simple process without many dependencies involved. But if the object creation policy is complex it is rather recommended to let individual classes handle it.
There are three more advantages that come with the usage of the Factory Pattern:
- We can control the number of instances of the object created since it is done at a centralized location.
- Any change in the object creation policy can easily be handled as it is done in one place(encapsulation) thereby promoting maintainability.
- Our entire code base can use this method to get the object instead of writing its own thereby promoting code reusability.
You can download the source code of the Factory Design Pattern from the following link:
Hope you liked the article!
