Demystifying the Abstract Factory Pattern: Building Multi-Cloud Infrastructure in C++

Have you ever wondered how cross-platform tools like Terraform, web browsers, or multi-cloud deployment platforms seamlessly swap out entire ecosystems under the hood without breaking client code?

Imagine building a cloud deployment tool where your users can deploy their infrastructure to AWS or Azure with a single toggle. You need servers, storage buckets, and database instances for both cloud providers.

If you use new EC2() or new S3Bucket() scattered across your entire application, your codebase will quickly turn into an unmaintainable maze of if-else conditionals. What if you accidentally pair an AWS EC2 instance with an Azure SQL Database?

This is precisely where the Abstract Factory Pattern shines. In this guide, we’ll break down the Abstract Factory pattern step-by-step using C++, diving deep into every single phase of implementation!

---

What is the Abstract Factory Pattern?

The Abstract Factory is a creational design pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Think of it as a “Factory of Factories”:

• Factory Method produces a single type of product (e.g., creating a single connection object).
• Abstract Factory produces a family of complementary products that belong together (e.g., creating AWS Storage + AWS Compute + AWS Database).

---

The 5-Phase Architecture Overview

To master the pattern, let’s break it down into 5 clear, manageable phases:

1. Product Interfaces (Blueprints): Abstract base classes defining what each product type does.
2. Concrete Products (The Items): Specific implementations for each family (AWS vs. Azure).
3. Abstract Factory (Factory Blueprint): An abstract interface defining factory creation methods.
4. Concrete Factories (Assembly Lines): Factories that construct items belonging to a specific family.
5. Client Code: High-level code that uses products strictly through interface pointers.

---

Complete C++ Code Implementation

Here is our full C++ blueprint modeling a multi-cloud infrastructure engine:

#include <iostream>
#include <string>

using namespace std;

// ==========================================
// PHASE 1: THE PRODUCT INTERFACES (Blueprints)
// ==========================================
class IStorage {
public:
    virtual void upload() = 0;
    virtual ~IStorage() = default;
};

class IServer {
public:
    virtual void boot() = 0;
    virtual ~IServer() = default;
};

class IDatabase {
public:
    virtual void connect() = 0;
    virtual ~IDatabase() = default;
};

// ==========================================
// PHASE 2: CONCRETE PRODUCTS (The Actual Items)
// ==========================================
// --- AWS Family ---
class S3Bucket : public IStorage {
public:
    void upload() override { cout << "Uploading to AWS S3" << endl; }
};

class EC2 : public IServer {
public:
    void boot() override { cout << "Booting AWS EC2 instance" << endl; }
};

class RDS : public IDatabase {
public:
    void connect() override { cout << "Connecting to AWS RDS" << endl; }
};

// --- Azure Family ---
class AzureBlobStorage : public IStorage {
public:
    void upload() override { cout << "Uploading to Azure blob storage" << endl; }
};

class AzureVM : public IServer {
public:
    void boot() override { cout << "Booting Azure instance" << endl; }
};

class AzureSQLDB : public IDatabase {
public:
    void connect() override { cout << "Connecting to Azure DB" << endl; }
};

// ==========================================
// PHASE 3: THE ABSTRACT FACTORY (Factory Blueprint)
// ==========================================
class ICloudFactory {
public:
    // Return POINTERS to the product interfaces!
    virtual IStorage* createStorage() = 0;
    virtual IServer* createServer() = 0;
    virtual IDatabase* createDatabase() = 0;

    virtual ~ICloudFactory() = default;
};

// ==========================================
// PHASE 4: CONCRETE FACTORIES (The Assembly Lines)
// ==========================================
class AwsFactory : public ICloudFactory {
public:
    IStorage* createStorage() override {
        return new S3Bucket(); // Returns an AWS product!
    }
    IServer* createServer() override {
        return new EC2();
    }
    IDatabase* createDatabase() override {
        return new RDS();
    }
};

class AzureFactory : public ICloudFactory {
public:
    IStorage* createStorage() override {
        return new AzureBlobStorage(); // Returns an Azure product!
    }
    IServer* createServer() override {
        return new AzureVM();
    }
    IDatabase* createDatabase() override {
        return new AzureSQLDB();
    }
};

// ==========================================
// PHASE 5: THE CLIENT CODE
// ==========================================
int main() {
    // 1. Create the factory using the Base Interface pointer
    // To switch to AWS, change this line to: ICloudFactory* factory = new AwsFactory();
    ICloudFactory* factory = new AzureFactory();

    // 2. Ask the factory to create the products
    IServer* myServer = factory->createServer();
    IStorage* myStorage = factory->createStorage();

    // 3. Use the products
    myServer->boot();
    myStorage->upload();

    // 4. Clean up memory! Every 'new' needs a 'delete'
    delete myServer;
    delete myStorage;
    delete factory;

    return 0;
}

---

Step-by-Step Code Walkthrough

Let’s inspect each section of the code and understand why it is written this way.

Phase 1: Product Interfaces

class IStorage {
public:
    virtual void upload() = 0;
    virtual ~IStorage() = default;
};

1. Pure Virtual Functions (= 0): upload(), boot(), and connect() are pure virtual functions. This turns IStorage, IServer, and IDatabase into Abstract Base Classes (interfaces in C++). You cannot instantiate them directly.
2. Virtual Destructors (virtual ~IStorage() = default;): Crucial in C++! When deleting a derived object through a base class pointer (delete myStorage;), a non-virtual destructor causes undefined behavior and memory leaks because derived destructors won’t be called.

---

Phase 2: Concrete Products

class S3Bucket : public IStorage {
public:
    void upload() override { cout << "Uploading to AWS S3" << endl; }
};

• Each concrete class inherits from its corresponding product interface and provides a concrete implementation for the pure virtual functions.
• The override keyword explicitly tells the compiler that we intend to override a virtual function from the parent class. If you mistype the function signature, the compiler throws an error immediately!

---

Phase 3: The Abstract Factory Interface

class ICloudFactory {
public:
    virtual IStorage* createStorage() = 0;
    virtual IServer* createServer() = 0;
    virtual IDatabase* createDatabase() = 0;
    virtual ~ICloudFactory() = default;
};

• ICloudFactory serves as the contract for all concrete cloud factories.
• Notice the return types: IStorage*, IServer*, and IDatabase*. The factory interface never references concrete classes like S3Bucket or AzureVM. It purely exposes product interfaces!

---

Phase 4: Concrete Factories

class AwsFactory : public ICloudFactory {
public:
    IStorage* createStorage() override { return new S3Bucket(); }
    IServer* createServer() override { return new EC2(); }
    IDatabase* createDatabase() override { return new RDS(); }
};

• AwsFactory guarantees that calling createStorage(), createServer(), and createDatabase() returns AWS products (S3Bucket, EC2, RDS).
• AzureFactory guarantees that the same calls return Azure products (AzureBlobStorage, AzureVM, AzureSQLDB).
• Family Consistency: You can never accidentally mix AWS storage with an Azure server because the factory you pass guarantees compatibility across all created resources.

---

Phase 5: Decoupled Client Code

int main() {
    ICloudFactory* factory = new AzureFactory();

    IServer* myServer = factory->createServer();
    IStorage* myStorage = factory->createStorage();

    myServer->boot();
    myStorage->upload();

    delete myServer;
    delete myStorage;
    delete factory;
    return 0;
}

Look closely at main(). Except for the single line where AzureFactory is instantiated, the rest of the code is 100% cloud-agnostic!

If you want to migrate your entire app to AWS tomorrow, you only update one line of code:

// Switch from Azure to AWS seamlessly!
ICloudFactory* factory = new AwsFactory();

---

When Should You Use the Abstract Factory Pattern?

Use the Abstract Factory pattern when:

• Your system needs to support multiple product families (e.g., AWS vs Azure, Dark Theme UI vs Light Theme UI, Windows GUI controls vs macOS GUI controls).
• You want to enforce consistency among related products (e.g., preventing a Mac button from being rendered inside a Windows dialog window).
• You want to isolate client code from concrete implementation classes.

---

Summary & Key Takeaways

Aspect	Factory Method	Abstract Factory
Focus	Creates a single product	Creates families of related products
Mechanism	Relies on inheritance or sub-classing	Relies on object composition & interface delegation
Flexibility	Easy to add new product types	Easy to add new product families (e.g., GCP)

By implementing the Abstract Factory Pattern, you decouple object usage from object creation, ensuring scalable, modular, and cloud-ready architectures. Happy coding!