Rescued by design patterns
Software Engineering is not just about writing code. It’s mostly about providing a solution to a problem. Recurring problems often find different solutions, one better than another, but at some point, software engineers are left to re-invent the wheel alone.
It would make sense to have a platform of solutions to such problems. The famous Gang of Four (not the post-punk band of course), created such a platform (https://springframework.guru/gang-of-four-design-patterns) specialised for object-oriented engineering, which goes by the name design patterns. The concept revolves around the definition of re-usable object-oriented software components.
A design pattern is not a ready-made piece of code that can be plugged into a software and run as is. It is also not a language agnostic solution that just needs to be translated into a specific programming language to work. It is a self-contained, re-usable (and in many cases extensible) guideline to a solution, a templated paradigm that will eventually provide the solution, a proven best practice.
Categorisation of design patterns comes from the type of problem they are meant to solve. Object creation is known to be a major area of object-oriented languages, so it is no surprise that Creational design patterns deal with the controlled way of creating objects. Object behaviour, being another major area, again yields no surprise that behavioural design patterns have templated common behaviour of objects, including their communication with other objects and even the world outside of their context. Finally, the definite need for structuring objects has led to the structural design patterns.
In this post we will take a view of the factory method creational design pattern and its usage, not in a tutorial format, nor as an example, but as a recipe.
As its classification suggests, the factory method design pattern deals with object creation. The immediate question that arises is: why do we need such a design pattern? Isn’t the new construction operator enough to create a new object? Well... not quite!
Imagine working on a software application for a car manufacturer that manages the production chain of cars. Usually, your application would be able to handle only the object that it was initially designed for, in our case cars. However, more often than not, we as software engineers are also asked to handle other, different kinds of objects. For instance, the car manufacturing company that we are working for has decided that they should also manufacture motorcycles. Unfortunately, our application is not able to handle the new object of motorcycle, unless we refactor the whole code. That's where the usage of the factory method pattern comes to save the day, or more realistically our sanity!
Supposing that a car and a motorcycle are different objects in the software. Their creation in the car manufacturer software surely depends on some parameters. A first approach to creating such objects would be an if-then-else block to decide on which object to create using its well-defined constructor based on the parameters. This block of code should be replicated in all places where an object needs to be created. Suppose that the car manufacturer was contracted to create an additional vehicle type, say a truck. That would create a nightmare for the software engineer, since he would need to amend the if-then-else piece of code to handle the new vehicle type in all existing places.
So, the first logical step would be to extract this piece of code responsible for object creation and localise it to a single place. Thus, any additional car manufacturer contracts for new vehicle types would require code amendments in a single place and not flood the existing code with the necessary amendments. That’s a good start, but it is still not enough. We need some common ground for the vehicle types creation so that we can simplify things even more. We can achieve this by using an interface that all vehicle types can implement and overload their constructor. That way, we can refer to object creation in a single piece of code all around the software, amend new concrete implementations in that single place, and add as many new types as the car manufacturer wants to contract with, leaving the software engineer’s sanity intact.
So you see, we’ve described the factory method without any code pertinent to any object-oriented language. By definition, a design pattern is a recipe, a paradigm description and not a code-specific solution. There are numerous examples you can find online for concrete implementation in all object-oriented languages.
