Polymorphic Factory Method

1. The Problem: Tight Coupling

Imagine you're building an application that needs to create different types of objects based on some input. A classic example is a document editor that can create different types of documents (.txt, .docx, .pdf). A naive implementation might look like this:

// Client code that needs to create a document
std::string userChoice = "docx";
Document* doc = nullptr;

if (userChoice == "txt") {
    doc = new TextDocument();
} else if (userChoice == "docx") {
    doc = new WordDocument();
} else if (userChoice == "pdf") {
    doc = new PdfDocument();
}
// ... use the doc ...
delete doc;

This code has a significant problem: the client code is tightly coupled to the concrete TextDocument, WordDocument, and PdfDocument classes. Every time you want to add a new document type (e.g., MarkdownDocument), you have to find and modify every if/else block like this in your application. This violates the Open/Closed Principle, which states that software entities should be open for extension but closed for modification.

2. A First Step: The Simple Factory Idiom

A common first step to improve this is to encapsulate the creation logic into a single function, often called a "Simple Factory."

As you saw, the code is now structured like this:

// Product interface
class IGameObject {
public:
    virtual ~IGameObject() = default;
    // ... other virtual functions
};

// Concrete products
class Plane : public IGameObject { /* ... */ };
class Boat : public IGameObject { /* ... */ };

// Enum for types
enum class ObjectType { Plane, Boat };

// Simple Factory function
IGameObject* makeGameObject(ObjectType type) {
    if (type == ObjectType::Plane) {
        return new Plane();
    } else if (type == ObjectType::Boat) {
        return new Boat();
    }
    return nullptr;
}

This is an improvement. The client code is now decoupled from the new expressions. If we add a Submarine class, we only need to modify the makeGameObject function. However, this still concentrates all creation logic in one place, which can become unwieldy. The true Factory Method pattern takes this one step further by using polymorphism.

3. The Factory Method Pattern

The Factory Method pattern lets subclasses handle the decision of which object to create. This is achieved by defining a virtual "factory method" in a base Creator class, which ConcreteCreator subclasses then override.

The structure is as follows:

• Product (e.g., Creature): Defines the interface for objects the factory method creates.
• ConcreteProduct (e.g., Dog, Cat): Implements the Product interface.
• Creator (e.g., Spawner): Declares the factory method, which returns an object of type Product. It can also define a default implementation.
• ConcreteCreator (e.g., DogSpawner, CatSpawner): Overrides the factory method to return an instance of a specific ConcreteProduct.

The key idea is that a DogSpawner's job is to spawn dogs, and a CatSpawner's job is to spawn cats. The client code can operate on a pointer to a generic Spawner without knowing or caring what specific kind of spawner it is; it just calls the factory method, and polymorphism ensures the correct type of creature is created.

// The Creator base class
class Spawner {
public:
    virtual ~Spawner() = default;
    // The Factory Method
    virtual Creature* spawn() = 0; 
    
    // Other business logic can use the spawn() method...
};

// A Concrete Creator
class DogSpawner : public Spawner {
public:
    Creature* spawn() override {
        return new Dog(); // Subclass decides what to create
    }
};

// Another Concrete Creator
class CatSpawner : public Spawner {
public:
    Creature* spawn() override {
        return new Cat();
    }
};

The client might use it like this:

// This spawner could have been chosen at runtime
Spawner* mySpawner = new DogSpawner(); 
Creature* myCreature = mySpawner->spawn(); // Guaranteed to be a Dog
// ... use myCreature ...
delete myCreature;
delete mySpawner;

4. Under the Hood: Polymorphism, Vtables, and Construction

Your goal is to understand how things work internally. The Factory Method relies entirely on C++'s runtime polymorphism, which is implemented via virtual tables (vtable) and virtual pointers (vptr).

When you call mySpawner->spawn(), the following happens:

1. The program follows the mySpawner pointer to the DogSpawner object in memory.
2. It finds the object's hidden vptr, which was set during construction to point to the DogSpawner's vtable.
3. It looks up the address for the spawn function within that vtable.
4. It calls the function at that address, which is DogSpawner::spawn.

This naturally leads to a question you might have: if we have virtual functions, why can't we have virtual constructors?

As the article explains, the vtable itself is set up by the constructor. A base class constructor sets the vptr to the base vtable, and then the derived class constructor updates it to the derived vtable. You can't use a mechanism (the vtable) to decide which function to call before that mechanism has even been built.

The Factory Method pattern is, in essence, a primary solution to the problem that constructors can't be virtual. It provides a polymorphic way to create objects.

5. From C-style to Modern C++: Ownership and Slicing

The examples we've seen use raw pointers (new/delete). In modern C++, this is a major red flag. It introduces two severe problems: ambiguous ownership and object slicing.

Key takeaways from the article:

1. Ownership: A function returning a raw pointer Creature* is ambiguous. Is the caller now responsible for calling delete (owning pointer), or is the creator still managing its lifetime (borrowing pointer)? This ambiguity leads to memory leaks or double deletions.
2. Slicing: If you ever accidentally copy a derived object into a base class object (e.g., by passing it by value), the derived part is "sliced off." You're left with just a base object, and all polymorphic behavior is lost. This is a subtle but deadly bug.
3. The Solution: Use smart pointers to manage ownership explicitly. std::unique_ptr is perfect for factories, as it clearly transfers unique ownership of the newly created object to the caller. It also prevents slicing because std::unique_ptr cannot be copied.

Let's refactor our Spawner example to use std::unique_ptr:

#include <memory>

class Spawner {
public:
    virtual ~Spawner() = default;
    // The factory method now returns a smart pointer
    virtual std::unique_ptr<Creature> spawn() = 0;
};

class DogSpawner : public Spawner {
public:
    std::unique_ptr<Creature> spawn() override {
        // std::make_unique is preferred for creating smart pointers
        return std::make_unique<Dog>();
    }
};

// Client code is now safer and cleaner
std::unique_ptr<Spawner> mySpawner = std::make_unique<DogSpawner>();
std::unique_ptr<Creature> myCreature = mySpawner->spawn(); // Ownership is transferred

// No need to call delete! The object is automatically destroyed when myCreature goes out of scope.

This is the canonical, modern C++ way to implement the Factory Method pattern.

Conclusion

Today we've added the Factory Method pattern to your design toolkit. It provides a powerful mechanism for decoupling object creation from client code, making your systems more flexible and easier to maintain.

Key Takeaways:

• The Factory Method pattern defines an interface for creating objects but lets subclasses override a virtual method to decide which concrete class to instantiate.
• It solves the problem of tight coupling, where client code depends directly on concrete classes, by adhering to the Open/Closed Principle.
• The pattern relies on C++'s runtime polymorphism, which is implemented through the vptr/vtable mechanism. This mechanism is set up by constructors, which is why constructors themselves cannot be virtual.
• In modern C++, the factory method should return a smart pointer, typically std::unique_ptr, to clearly express ownership transfer and prevent dangerous bugs like memory leaks and object slicing.

In the next lesson, we will explore the Builder pattern. While the Factory Method is about creating one of several possible objects from a class hierarchy, the Builder pattern focuses on constructing a single, complex object step-by-step, separating the object's construction from its representation.