Previously we have covered Adapter Design Pattern, which you can read about here.
Problem to solve
Imagine a project, where you have to access complex Data from various sources like Data Bases, APIs, file uploads etc. All that information has to be consumed and used by your application code.
In most cases you will be operating with
JSON objects. As you probably know
JSON is an incredibly simple Object Type. Therefore, if we just use Raw JSON in our application, we are exposing our code to a variety of issues.
#1 Object Structure
We are not in control of the structure of these objects. If we are going to use these objects as we receive them, we are adding risk to our code to break in multiple places, if data properties will change. Good example might be, if an API data source has changed its response object or someone renamed a column in Data Base, this will change the structure of the object your code receives.
This will lead to a broken code and bugs in multiple places, due to wrong properties being used.
#2 Codebase Consistency
We are exposing our code to a huge inconsistency. If you receive similar data, like for example
Book object from more than one source, there is a chance, that two same books may look different from an Object perspective.
General idea is that, we are not in control of our Domains. But the opposite, we are led by outside data structures. So instead of building an application around your own data implementation you will be building you implementation around data structures dictated by outside sources.
This issue is quite big, because it takes over your codebase conventions and standards.
#3 Object Type
We are unable to confirm which object type we are operating with at a particular point in time. For example, we may end-up with using Book Object as User or a Blog Post object.
As you can see from the example above, we are not able to determine to which instance each JSON object belongs.
Principal of Factory Pattern is incredibly simple in its core. This pattern is categorised as Creational, and there is a reason for that. Factory is designed to create. And when we speak about programming, we want it to create Objects, which follow our Domain conventions.
Though as I said in my previous article about Adapter Pattern, the KEY here is the concept itself, which can make our code cleaner and more robust, not an exact 1:1 implementation from a book.
Factory Pattern — simple diagram
This is how we can visualise our codebase consuming and handling data without Factory Pattern. As you can see everything is leaking to our main codebase in a Raw state, with potentially small tweaks and transformations.
On the diagram below we can see a simple visualisation of how situation changes if we are using Factory Pattern where it’s appropriate.
Factory Pattern — code example
Let’s imagine a small application, with this structure.
We have simple entry point
domain/ area where we have our own definitions of objects we want to manipulate within our code.
A simple example of the Book Domain Object may look like this:
Bear in mind these code samples are massively simplified. In case of the Book Domain Object, we have a simple
class with three properties —
pages which WE define, and we can be 100% sure they will never change.
Now, let’s see the Factory:
As you can see its really simple
class which also can be a
function really if you are in completely functional programming paradigm. The last step is to use our Factory.
And this is it! This is how simple the pattern is. Let see also what other benefits it gives us now.
As you can see intellisense is now assisting us with available properties and methods from our Domain Object.
We are 100% sure, that structure will be same for all instances of the Book Object we create from various sources including our own code — for example if we decide to create completely new Book Object.
We also can see the actual type of the Object we are operating right now.
And we can see an instance of which class we are working with. This is giving us some sort of a Type control — you can build more robust code with better Unit Test and validation of data you are using.
Quick, one sentence summary.
Factory creates Domain Objects, from fragile or vulnerable data structures.
Thank you for taking time and reading this article. I really hope, you have gained some good insights and became even better engineer.
Have a great time, do things you love and see you in the next post. 🔥
A note from the Plain English team
And as always, Plain English wants to help promote good content. If you have an article that you would like to submit to any of our publications, send an email to firstname.lastname@example.org with your Medium username and what you are interested in writing about and we will get back to you!