Factory Method Pattern | C++ Design Patterns

The Factory Method Pattern is a creational design pattern that provides an interface for creating objects while allowing subclasses or factory classes to decide which object to instantiate. It separates object creation logic from client code, improving flexibility and reducing tight coupling.

• It hides the details of object creation from the client and allows different object types to be created through a common interface.
• It improves flexibility and maintainability by enabling object creation to be decided dynamically at runtime.

Use Cases of Factory Method

The Factory Method Pattern is commonly used when object creation needs to be flexible, centralized, and independent from the client code.

• To simplify and centralize object creation logic.
• To hide the details of concrete class instantiation from the client.
• To create different types of objects through a common interface.
• To decide object creation dynamically at runtime based on requirements.

Real-World Use Cases

The Factory Method pattern is widely used in software development to create objects dynamically based on runtime conditions.

• Logger Factory: Creates different types of loggers.
• Database Connector: Creates connectors for MySQL, PostgreSQL, etc.
• UI Component Factory: Used in frameworks like Qt or JavaFX.
• Game Object Factory: Creates enemies, power-ups, etc., in games.

Core Components

The Factory Method Pattern consists of several key components that work together to separate object creation from object usage.

• Product: Defines a common interface or abstract base class for all objects created by the factory.
• Concrete Product: Represents the actual object or class that implements the Product interface.
• Creator: Declares the factory method responsible for object creation.
• Concrete Creator: Overrides the factory method to create and return specific Concrete Product objects.

Implementation of the Factory Method in C++

Let’s implement the Factory Method Pattern step by step with a dynamic shape example, which shows the real benefit of the pattern.

Step 1: Abstract Product – Shape

class Shape {
public:
    virtual void draw() = 0; // Pure virtual function
    virtual ~Shape() {}
};

• This base class defines a common interface for all shapes.
• Every shape must implement the draw() function.

Step 2: Concrete Products – Circle and Square

class Circle : public Shape {
public:
    void draw() override {
        std::cout << "Drawing Circle\n";
    }
};

class Square : public Shape {
public:
    void draw() override {
        std::cout << "Drawing Square\n";
    }
};

• These classes implement the Shape interface.
• Each class defines its own version of draw().

Step 3: Abstract Creator – ShapeFactory

class ShapeFactory {
public:
    virtual Shape* createShape() = 0; // Factory method
    virtual ~ShapeFactory() {}
};

• Declares a method createShape() but doesn’t implement it.
• Subclasses or implementations provide the actual object creation logic.

Step 4: Concrete Creators – CircleFactory and SquareFactory

class CircleFactory : public ShapeFactory {
public:
    Shape* createShape() override {
        return new Circle();
    }
};

class SquareFactory : public ShapeFactory {
public:
    Shape* createShape() override {
        return new Square();
    }
};

• These factories override createShape() to create the correct object.

Step 5: Dynamic Client Code

ShapeFactory* getFactory(char type) {
    if (type == 'C') return new CircleFactory();
    else if (type == 'S') return new SquareFactory();
    return nullptr;
}

int main() {
    char userChoice;
    cout << "Enter C for Circle, S for Square: ";
    cin >> userChoice;

    ShapeFactory* factory = getFactory(userChoice);
    if(factory) {
        Shape* shape = factory->createShape();
        shape->draw();
        delete shape;
        delete factory;
    }

    return 0;
}

• The main function creates factories and uses them to get shapes.
• The decision of which object to create happens at runtime.
• Client only interacts with Shape*, not Circle or Square.

Advantages

The Factory Method pattern provides several benefits that improve code flexibility and maintainability:

• Loose Coupling: Client doesn’t depend on concrete classes.
• Easy to Extend: Add new types by creating new factories.
• Cleaner Code: Object creation logic is in one place.
• Supports Polymorphism: You can treat all shapes uniformly.

Disadvantages

Despite its benefits, the Factory Method pattern also has some drawbacks to consider:

• More Classes: One factory per product type increases class count.
• More Complexity: Not worth using for very simple object creation.
• Subclassing Needed: Every new type needs a new factory subclass.