"New is glue"

was in my Top 10 TILs of this month, it's so intuitive yet not so explicit. It's so self explanatory yet not so simple enough to execute. What it says is that, by using the "new" keyword in a code flow, you're binding the code to the creation of a new object and that goes against the "Code to an interface and not an implementation" principle.

Factory pattern talks exactly about the same, it's a creational design pattern which decouples object creation from the main logic/code flow. If you think about it, this approach has many "off the top of my head" advantages, like any modification on the object creation like addition of any attribute or introducing polymorphism can be done without disturbing the main logic.

The example above, is the simplest implementation of the Factory pattern you can find on the internet. In order to understand it deeper, let's start by an example, Chairs and Pizzas have become too common, so for a change, lets consider Credit Cards! Lets create a CreditCardFactory that manufactures cards for us.

Now let's say your marketing team decides that there's going to be a new type of credit card to be introduced which is "Ultra Premium Card", and as you might have expected already in order to create this object in your code base, you only need to make a small "modification" ( notice the quotes, you'll know why later )

You might think, that this implementation is fairly straight forward and like all the other engineers tell yourself that "I wiLL sUreLy uSe iT fRom nOw" and move on. But that's where things start getting interesting, consider this to be the climax of this blogpost.

if you look at the above snippet carefully, it actually disobeys OCP (Open Closed Principle), which states that the code should always be open for extension and close for modification. In the future, it's fairly obvious that there may be other types of credit cards that are to be included, which would mean for you to go to the CreditCardFactory class and CHANGE the logic of creation or modify the way in which the card objects are created, which basically means that your code is OPEN for modification.

Now you might think, so what? It's not like you HAVE TO follow SOLID principles always, duh! bear with me and I'll show you why, you should, atleast for this use case.
If you do the modification like in the above snippet, your team would have to test the whole Factory class again, because if there was the change done in the class, and any small error which could've been made while making that change if it breaks the Factory class, which in turn sabotages the creation of all the objects here after.

Hence, write your code in such a way that, in order to implement something new, you don't have to change your existing code base but add some extra code instead, that my friends is the true meaning of making your codebase open for extension and closed for modification

Lets see how can that be done..

I hope with this you've understood both what and why of Factory patterns. Any discrepancies you find in the code/text please feel to mailme@kunaldubey.com

Peace!