This design pattern helps you control the classes of objects that an application creates. The responsibility of creating the product objects is encapsulated within the factory, and the client remains blissfully unaware of which concrete objects it's using and how they are created, interacting only with the abstract classes for factory and objects.

Abstract Factory also allows exchanging product families easy. We can use entirely different families of related products by just changing which concrete instance of the abstract factory the application is using. Just create a new concrete factory by making a subclass of the abstract factory and override the operations/products that need to change.

When to Use
  1. a system should be independent of how its products are created and composed. 
  2. a system should be configured with one of multiple families of products. 
  3. a family of related product objects is designed to be used together, and you need to enforce this constraint. 
  4. You might need to support different families of products in the future. 
Participating Classes 
image.png
  1. AbstractFactory
    • Declares an interface for operations that create abstract product objects.
  2. ConcreteFactory
    • Implements the operations to create concrete product objects.
  3. AbstractProduct
    • Declares an interface for a type of product object.
  4. ConcreteProduct
    • Defines a product object to be created by the corresponding concrete factory, and implements the interface defined by AbstractProduct.  
  5. Client
    • Uses only the interfaces declared by AbstractFactory and AbstractProduct classes.