The Factory Pattern

The Factory Pattern

The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.

Let’s understand this with a real life case. The famous burger franchise, let’s name it B-King, has decided to open a series of restaurants in the most popular cities like New York, London, and New Delhi. Each restaurant has unique style of making burger which tastes unique as well. For example, NY Style cheese burger tastes different than Bangalore Style cheese burger. But each restaurant should have the capability to create burger and order burger.

How do we solve this problem?

Don’t worry! We have a solution called factory method pattern.

Let’s create an abstract class BurgerStore which will have two methods called “createBurger” and “orderBurger”. Similarly, there will be NYBurgerStore, LondonBurgerStore, and NDBurgerStore which will inherit from the abstract BurgerStore class and overwrite createBurger Store to create burger based on restaurant uniqueness.

The Factory Pattern

Let’s define product i.e. Burger classes.

The product classes

It is clear that abstract classes are extended by concrete classes, which know about specific implementation for New York, London, and New Delhi.

The NYStyleStore encapsulate all the knowledge about how to make NY style burgers. Similar is the case with LondonStyleStore and NDStyleStore. The important thing here is that the factory method is the key to encapsulating this knowledge.

It should be pretty clear that reducing dependencies to concrete classes in our code is a “good thing”. In fact, we have got an OO design principle:

Design Principle

Depend upon abstractions. Do not depend upon concrete classes.

If you are not clear about this principle says. Don’t worry! We will extend our existing problem and solve it to understand the said principle.

Let’s say that New York region uses one set of ingredient and New Delhi another. Now, the challenge is that how to handle families of ingredients.

To solve this problem, we will build a factory called BurgerIngredientFactory which will be extended by regional ingredient factories to create families of ingredients.

The solution would look like this:

The Abstract Factory Pattern

The abstract BurgerIngredientFactory is the interface the defines how to make a family of related products everything we need to make a burger. The task of the concrete burger factories is to make burger ingredients for their region.

Each factory produces different implementation for the family of products.

Congratulations! You have just learned a variant of the factory pattern which is called the abstract factory design pattern.

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Wait! What? The Factory pattern and the Abstract Factory pattern are different. Yes, both are different. Still confused! Don’t worry! Here are the top differences:

1. Factory pattern uses classes to create while Abstract Factory pattern uses objects; that’s totally different!
2. Factory pattern uses inheritance while Abstract Factory pattern uses object composition.
3. Factory pattern lets subclasses instantiate concrete classes while Abstract Factory pattern defined a family of related objects.

Final Notes

1. Use Abstract Factory pattern, whenever you have families of products that you need to create and you want to make sure that your client create products that belong together.
2. Use Factory pattern, whenever you want to decouple your client code from the concrete classes you need to instantiate or you don’t know ahead of time.