Design Pattern — Creational — Low level system design — Factory and Abstract Factory (part 1)
Creational Design Pattern deals with the way you can structure your code base in terms of creating objects in order to provide flexibility on object creations, API versioning and reusing existing code.
Why is it important to learn this design pattern?
Well, often we make a mistake of writing codes without giving a thought about future issues which our code would bring in. As and then the user base grows, flexibility to support versioning of say APIS, modules, factory, service classes etc., becomes a huge overload. If we understand and write the code structure well before we create new services then this may solve a lot of future havoc. So let’s dive into the code in order to understand how it’s done
Key creational design patterns:
1. Factory Design Pattern
2. Abstract Factory Design Pattern
3. Builder
4. Prototype
5. Singleton
1. Factory Design pattern
Factory design pattern deals with creation of services in such a way that it provides easy flexibility on versioning of the code.
Let’ take a example use case
Every project today generally access Database with the help of some ORMs. What if one ORM is awesome with speed of read while other ORM is good in writing data by providing various extensive options. You may generally end up using just one of the ORMs overall in your code base rather than switching ORMs because it would be hard to implement such functionality switches. Let’s take the same example and understand how Factory design pattern can solve such a case
Before knowing factory pattern design, the way a dev would generally write code will look like
What are the issues above?
In factory design pattern basically we define an interface which declares the common pattern which is used across the different functionalities. Like in above case, different ORMs pattern such as opening connection, checking if table is existing and creating a table later and then closing the connection. These CRUD operations will be common for all ORMs so here’s where we define an interface for crud operations and this interface can be further implemented by various classes. Please find the below code explaining about the same which is the classic example of factory design pattern.
After knowing factory design pattern
Example 2: One more classical example use case for this design pattern is API versioning. Every product over the period of time requires revamping and launching a new version 2 of the product so ensuring that code is backward compatible is pretty difficult if its not well documented (which is most of the times the case in companies). Here, use of factory design pattern solves one such criticality. Please find the below code example to understand on the same
So in above code as you can see, whenever you wanna write new API class payments, it’s just having great clarity as well as making it well backward compatible.
So what’s improved?
1. Code consistency: We have identified that code pattern has a repetition so creating an interface ensures that when we add a new future ORM, its backward compatible with all other CRMs.
2. Code versioning: Introducing new verison of the code will be relatively easy as mentioned in the above example.
3. Code clarity: Code reading clarity improves a lot. As there is a common interface now which declares all the methods needed to be implemented in relevant classes, it becomes very easy to read and write new requirements.
2. Abstract Factory Design pattern
It’s quite similar to Factory design pattern. If you understood factory well then it’s easy to understand this. It basically says to use factory on top of another factory with the use of abstract classes.
Example:
In above example cases explained for factory design pattern, we are creating APIs and providing versioning on them. If we try to combine the above examples then it would become a classic example of Abstract Factory design pattern.
Lets say we have are creating payments service and for every payments service we may need to select any one of the many ORMs configured in the product. Achieving this defines the use of abstract factory design pattern where we create an ORMfactory which is used by PaymentsService Factory.
Here we use abstract class because it allows us to define certain methods which can act as a common methods across the classes extending it unlike interfaces.
Please fine the part 2 for this medium article below
