Design Pattern Series, Abstract Factory 
Tags: designpattern, design
Published: 2019-10-25 17:31:39

First all Hello fellow Devian's.This is my first series to write proper articles in the field of Design Patterns. So if I am wrong somewhere, please feel free to correct me in the comments section.

I decided to create this series as a part of my learning journey. So ready to  start  the first one




Abstract Factory Pattern is included in the Creational Design Pattern. As it provides an interface for creating families of related or dependent objects without specifying their concrete class. Abstract Factory Pattern is like a Factory design pattern (we will see this later in the series). Basically, Abstract Factory is a super-factory pattern, as it has another layer of abstraction over factory pattern.
We can implement the Abstract Factory Pattern when objects tend to follow this kind of model. At runtime, the Abstract Factory is coupled with any concrete factory class which can create objects of the desired type.
A little Sneak Peek into the Abstract Factory UML model:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/itza5l85eptlgjuzssbz.png) 

Basic Terms used in UML:
Client: Uses only Interface declared by Abstract factory and Abstract Product classes.
Product: Defines a product object to be created by the corresponding concrete factory and implements the Abstract Product Interface.
Concrete Factory: Implements the operations declared in the Abstract factory to create concrete Products.
Abstract Factory: Declares an interface for operations that create abstract product objects. 



The gist of Abstract Factory Pattern:
So Abstract factory just provides interfaces for creating families of related or dependent objects without specifying their concrete class.
The client creates a concrete implementation of the abstract factory and then uses the generic interfaces to create concrete objects. Client doesn’t care about which concrete it gets from the Abstract factory. As it makes use of the general interfaces.

Applicability:
•	A system should be independent of how its products are created, composed, and represented.
•	A system should be configured with one of the multiple families of products.
•	A family of related product objects is designed to be used together, and the designer must enforce it.
•	You want to provide the class library of products, and just want to reveal the interfaces, not their implementations.

Pros:
This pattern is successful when the client doesn’t know what exactly he/she wants to create.
•	Isolation of Concrete Classes, The pattern basically helps you control the classes of objects. Because a factory encapsulates the process of creating product objects. Thus, the client manipulates instances through their abstract interfaces.
•	Product families are exchanged very easily, The concrete factory class appears only once in an application, where it’s instantiated. This makes it easy to change the concrete factory an application uses.
•	Consistency should prevail among the products that are being created. As it’s important that an application use objects from only one family at a time. So the Abstract factory makes this task easier.

Cons:
•	It’s difficult to support new kinds of products in the Abstract factory. That’s because Abstract factory interfaces fix the set of products that can be created. It is difficult to modify the whole architecture when a new product is added to the Abstract factory.  Supporting new kinds of products requires extending the factory interface, which involves changing the Abstract factory class and all its subclasses.