Design Patterns part 2 — Factory Method Pattern
In this article, I am going to talk discuss Factory Method Pattern. This is one of the creational design patterns and this is also known as a Virtual Constructor. Generally in Java, we use new keyword to create the object of a class. This is perfectly fine for small programs. But think of an enterprise-level large-scale application then it will become complex to manage the code. In the Singleton pattern, we don’t create instances using the new keyword, and here also the same. Simply, we can understand it from the name itself, making use of classes that act as factories to create objects out of them. So in this pattern, we define an interface (it will be the superclass) which can be a Java Interface or abstract class to create objects but allows concrete subclasses to change the type of objects, that will be instantiated. Most importantly, the subclasses implement the factory method to choose the class for which objects must be created. The main advantage of using this pattern is we can create loosely coupled systems and we can create objects without exposing the creation logic to the client.
So this is how it works, we will create an interface or an abstract class for the main object and several classes(concrete) which implement the main object. Then we create a factory to instantiate the object based on the given information. Finally, in the Application, we pass the information to the factory as a parameter to instantiate.
Let's see a use-case for further understanding,
Let's implement a small train ticket system, which takes ticket type and number of seats as inputs. Based on the ticket type, the ticket value will be assigned and returns the total ticket price according to the number of seats. You can see the basic structure of the system that I mentioned here.
Let's look at the code,
So this is the enum for the ticket types. Actually, this is optional because I can directly check the keyword in the factory itself but it is better to keep it separate to maintain a clean code.
This is the abstract class of Ticket which holds the variable to get the ticket fare and a function to set that value. So each concrete class will be extended from this class. Now let's check the concrete classes,
These are the concrete classes that extend the Ticket abstract class and each concrete class is having the setTicketFare() method to set the value of the ticketFare . So based on the enum value, setTicketFare() method will be overridden. Now let's create a factory class,
This class is responsible for deciding from which class the object should be instantiated. So based on the parameter, this method will create and return the instance from a concrete class. Now let's implement the main method,
As you can see from the above code, I am printing the initial details then the user has to enter the number as he/she wants. Then I am getting the number of seats as an input. So in the switch statement, an object will be created based on the type that user selected. Then I invoke the setTicketFare() method. After the calculation, the total is stored in the amount variable and finally, it is printed as an output.
As an example, if I am selecting the first-class and giving 2 as the input for the number of seats then the output will look like the following screenshot,
So in this design pattern, users won’t be able to directly see the initiation logic but only the factory class. When it comes to the advantages of this design pattern, through inheritance, it gives abstraction between implementation and client classes and makes our code less coupled, robust and we can extend very easily.
When it comes to usage we can use this design pattern when,
- the creation of sub-classes is not finalized in a class
- the product implementation will evolve over time, but the client will remain the same.
References
I have referred to the following YouTube video to write this article, which was made by Krishantha Dinesh