Abstract Factory Design Pattern

Abstract factory method design pattern :- basically it is a pattern inside a pattern it is a creational design pattern which is required to create objects which belong to a family of similar objects the way we had factory design pattern where we created objects which are of similar type here we are using a factory of factory to create objects which belong to a family of similar objects.

Difference between factory and abstract factory design pattern

The Abstract Factory Pattern is similar to the Factory Method Pattern, but with one extra layer. In the Abstract Factory, there's a central interface (or "factory") that defines methods to create a group of related objects (like buttons or checkboxes).

Each Concrete Factory class decides which specific factory (for example, one for Windows or Mac) will be used to create the actual objects. The logic for creating the final objects (like a Mac button or a Windows checkbox) is then implemented in these Concrete Product classes.

In short:

1. The Abstract Factory defines methods to create families of objects.
2. Concrete Factories decide which specific factory to use based on some logic.
3. The Concrete Products (actual objects) are created based on the logic in these factories.

This pattern helps create related objects without tightly coupling the code to specific implementations.

Class Diagram of abstract factory design pattern

        +----------------------+
        |   AbstractFactory     | <------------------------------+
        |---------------------- |                                  |
        | + createProductA()    |                                  |
        | + createProductB()    |                                  |
        +----------------------+                                   |
                  ^                                                |
                  |                                                |
   +-------------------------+             +-------------------------+
   |     ConcreteFactory1     |             |     ConcreteFactory2     |
   |------------------------- |             |-------------------------|
   | + createProductA()       |             | + createProductA()       |
   | + createProductB()       |             | + createProductB()       |
   +-------------------------+             +-------------------------+
            |                                       |
            |                                       |
    +---------------+                      +---------------+
    |   ProductA1   |                      |   ProductA2   |
    +---------------+                      +---------------+
    +---------------+                      +---------------+
    |   ProductB1   |                      |   ProductB2   |
    +---------------+                      +---------------+

Analogy to understand abstract factory design pattern: Smartphone Manufacturer

Imagine a smartphone company that offers two product lines: Android and iPhone. Both lines include a Phone and a Charger, but the specific models for each line differ.

A smartphone company makes two product lines: Android and iPhone, each having a Phone and a Charger.

• Abstract Factory: Think of it as the blueprint that defines which products (Phone and Charger) need to be created.
• Concrete Factories: These are like the Android and iPhone departments, responsible for creating specific products based on the line chosen (Android or iPhone).
• Concrete Products: The actual items (Android Phone, Android Charger, iPhone, iPhone Charger) made by the departments.
• Client: You, as the customer, choose between Android or iPhone, and the right products are created for you without needing to know how they are built. This pattern ensures compatible products (Phone and Charger) are created together without exposing the internal creation logic.

Following is UML diagram for above analogy

                 +--------------------+
                 |   AbstractFactory   |  <--- Abstract Interface for creating products
                 +--------------------+
                 | + createPhone()     |
                 | + createCharger()   |
                 +--------------------+
                          /\
                          ||
        +-------------------------------------------+
        |                                           |
+----------------------+                  +----------------------+
|  AndroidFactory      |                  |  iPhoneFactory       |  <-- Concrete Factories
+----------------------+                  +----------------------+
| + createPhone()      |                  | + createPhone()      |
| + createCharger()    |                  | + createCharger()    |
+----------------------+                  +----------------------+
        /\                                      /\
        ||                                      ||
+-------------------+                +-------------------+
| AndroidPhone      |                | iPhone            |  <-- Concrete Products
+-------------------+                +-------------------+
| + makeCall()      |                | + makeCall()      |
+-------------------+                +-------------------+
+-------------------+                +-------------------+
| AndroidCharger    |                | iPhoneCharger     |  <-- Concrete Products
+-------------------+                +-------------------+
| + charge()        |                | + charge()        |
+-------------------+                +-------------------+

Client
+----------------------------------+                <-- Client Code
| Calls either AndroidFactory or   |
| iPhoneFactory to get products    |
+----------------------------------+

Here is code for above analogy to understand in a better way

// Abstract Factory
class AbstractFactory {
  createPhone() {
    throw new Error('This method should be overridden');
  }

  createCharger() {
    throw new Error('This method should be overridden');
  }
}

// Concrete Factory for Android
class AndroidFactory extends AbstractFactory {
  createPhone() {
    return new AndroidPhone();
  }

  createCharger() {
    return new AndroidCharger();
  }
}

// Concrete Factory for iPhone
class iPhoneFactory extends AbstractFactory {
  createPhone() {
    return new iPhone();
  }

  createCharger() {
    return new iPhoneCharger();
  }
}

// Product classes for Android
class AndroidPhone {
  makeCall() {
    return 'Making a call from Android Phone';
  }
}

class AndroidCharger {
  charge() {
    return 'Charging Android Phone';
  }
}

// Product classes for iPhone
class iPhone {
  makeCall() {
    return 'Making a call from iPhone';
  }
}

class iPhoneCharger {
  charge() {
    return 'Charging iPhone';
  }
}

// Client code
function getFactory(osType) {
  switch (osType) {
    case 'Android':
      return new AndroidFactory();
    case 'iPhone':
      return new iPhoneFactory();
    default:
      throw new Error('Unknown OS type');
  }
}

// Example usage
const androidFactory = getFactory('Android');
const androidPhone = androidFactory.createPhone();
const androidCharger = androidFactory.createCharger();

console.log(androidPhone.makeCall());  // Output: Making a call from Android Phone
console.log(androidCharger.charge());  // Output: Charging Android Phone

const iphoneFactory = getFactory('iPhone');
const iphone = iphoneFactory.createPhone();
const iphoneCharger = iphoneFactory.createCharger();

console.log(iphone.makeCall());        // Output: Making a call from iPhone
console.log(iphoneCharger.charge());   // Output: Charging iPhone

The Abstract Factory Pattern is a powerful design approach that promotes the creation of families of related objects without specifying their exact classes. By decoupling the client code from the actual product creation, it ensures flexibility, scalability, and cleaner code management when introducing new product families. Whether it's for managing cross-platform interfaces or creating different product lines, this pattern offers a structured and maintainable solution for handling object creation complexities. Implementing the Abstract Factory helps you future-proof your code and maintain clear separation of concerns as your system evolves.

I would love to hear how you've applied these ideas to your work? Share your thoughts or questions in the comments below—I’d love to hear from you.

Thank you for joining me on this learning journey!