bookforge-abstract-factory-implementor（bookforge 抽象工厂实现者）

Abstract Factory Implementor

When to Use

You are creating families of related objects and the client must stay independent of which concrete family it uses. This skill applies under four specific conditions — all are sufficient; any one justifies the pattern:

1. Product-creation independence — a system should not depend on how its products are created, composed, or represented. Clients should work against abstract interfaces, not constructor calls.
2. Multiple product families — the system must be configured with one of several families of products (e.g., Motif widgets vs. Presentation Manager widgets vs. Mac widgets), and the choice of family should be a single point of configuration, not scattered throughout the codebase.
3. Enforced co-usage — products within a family are designed to work together, and you need a structural guarantee that clients never mix products from different families (a MotifScrollBar with a PMButton, for instance, is a violation the pattern makes structurally impossible).
4. Interface-only library — you are providing a class library and want to reveal only interfaces, not implementations. Clients code against the abstract factory and abstract product classes; the concrete implementations are deployment-time choices.

Before starting, confirm this is not a simpler case:

• If only one product type varies, prefer Factory Method — Abstract Factory is for *families* of products that must vary together.
• If the products are not related (no co-usage constraint), the coordination overhead of Abstract Factory is not justified.

Process

Step 1: Set Up Tracking and Map the Product Families

ACTION: Use TodoWrite to track progress, then identify all product types and all families.

WHY: The Abstract Factory interface is fixed at design time based on the product types you identify here. Missing a product type now means changing the AbstractFactory interface later, which requires updating every ConcreteFactory — the most expensive structural change possible. A complete product-family map made upfront prevents this.

TodoWrite:
- [ ] Step 1: Map product types and product families
- [ ] Step 2: Define AbstractProduct interfaces
- [ ] Step 3: Define the AbstractFactory interface
- [ ] Step 4: Implement ConcreteFactory classes
- [ ] Step 5: Wire the client to use the factory
- [ ] Step 6: Handle singleton, prototype, or extensibility concerns
- [ ] Step 7: Validate and document known trade-offs

Applicability gate — confirm at least one of these four GoF conditions holds before proceeding:

IF none hold → this is not an Abstract Factory problem. Consider Factory Method (single product) or Builder (complex construction).

Alternative to consider — Prototype-based factory: If many product families exist or families differ only slightly, a single factory initialized with prototype instances (cloning instead of subclassing) eliminates the ConcreteFactory subclass explosion. Evaluate this option in Step 6 — but be aware of it now so you don't commit to a subclass-per-family design prematurely.

Produce a product matrix before writing any code:

The columns are your ConcreteFactories. The rows are your AbstractProduct interfaces. Count the rows — that is the number of factory methods on your AbstractFactory interface.

Step 2: Define AbstractProduct Interfaces

ACTION: For each product type (each row in the matrix), declare an abstract interface or base class.

WHY: The AbstractProduct interfaces are the contracts the client codes against. They are what make the client independent of concrete classes. Every method the client needs to call on a product must appear on the AbstractProduct interface — if a client has to downcast to access concrete behavior, the interface is incomplete and the isolation benefit disappears.

For each product type:

1. Name it for the domain concept, not the family (e.g., ScrollBar, not MotifScrollBar)
2. Declare only the operations all families must support
3. Keep it minimal — only what the client actually calls

See the reference file for full code examples in C++, Python, and Smalltalk.

Step 3: Define the AbstractFactory Interface

ACTION: Declare an abstract factory class with one creation method per product type.

WHY: The AbstractFactory interface encodes the complete set of products the system knows about. Its method signatures return AbstractProduct types, never concrete types — this is what prevents concrete class names from appearing in client code. The factory interface is the "catalog" of the product family; each ConcreteFactory is one edition of that catalog.

class GUIFactory {
public:
    virtual ScrollBar* CreateScrollBar() = 0;
    virtual Button*    CreateButton()    = 0;
    virtual Menu*      CreateMenu()      = 0;
    virtual ~GUIFactory() = default;
};

Naming convention: Prefix with Create (C++/Java) or create_ (Python). This makes factory methods instantly recognizable in code review and distinguishes them from ordinary method calls.

Step 4: Implement ConcreteFactory Classes

ACTION: For each product family (each column in the matrix), create a ConcreteFactory subclass that implements every creation method.

WHY: Each ConcreteFactory encapsulates complete knowledge of one product family. A client that holds a MotifFactory reference is guaranteed to receive only Motif products — the factory enforces the co-usage constraint structurally, not through documentation or convention. This is the core value: consistency across a product family is automatic, not policed.

class MotifFactory : public GUIFactory {
public:
    ScrollBar* CreateScrollBar() override { return new MotifScrollBar; }
    Button*    CreateButton()    override { return new MotifButton; }
    Menu*      CreateMenu()      override { return new MotifMenu; }
};

class PMFactory : public GUIFactory {
public:
    ScrollBar* CreateScrollBar() override { return new PMScrollBar; }
    Button*    CreateButton()    override { return new PMButton; }
    Menu*      CreateMenu()      override { return new PMMenu; }
};

For each ConcreteFactory, implement the corresponding ConcreteProduct classes:

class MotifScrollBar : public ScrollBar {
public:
    void ScrollTo(int position) override {
        // Motif-specific scroll rendering
    }
};

class PMScrollBar : public ScrollBar {
public:
    void ScrollTo(int position) override {
        // Presentation Manager scroll rendering
    }
};

Step 5: Wire the Client to Use the Factory

ACTION: Refactor the client to receive an AbstractFactory reference and call only factory methods and AbstractProduct interfaces — no new ConcreteProduct(...) calls anywhere in client code.

WHY: The client has to commit to using the factory interface consistently. A single stray new MotifScrollBar in the client code breaks the isolation guarantee — the concrete class name is back in client code and the family-switching benefit is lost. This step is not complete until grep finds zero concrete class names imported or instantiated in client code.

Before (hard-coded, platform-specific):

// Every widget creation exposes a concrete class name
ScrollBar* sb = new MotifScrollBar;
Button* btn   = new MotifButton;
Menu* menu    = new MotifMenu;

After (factory-mediated, platform-independent):

void Application::BuildInterface(GUIFactory* factory) {
    // No concrete class names — family is entirely encapsulated in factory
    ScrollBar* sb  = factory->CreateScrollBar();
    Button*    btn = factory->CreateButton();
    Menu*      menu = factory->CreateMenu();
    // ...
}

Factory initialization — this must happen once, before the client first needs a product, at the program's configuration point:

// Compile-time known family
GUIFactory* guiFactory = new MotifFactory;

// Runtime-selected family (environment or config)
const char* styleName = getenv("LOOK_AND_FEEL");
if (strcmp(styleName, "Motif") == 0) {
    guiFactory = new MotifFactory;
} else if (strcmp(styleName, "Presentation_Manager") == 0) {
    guiFactory = new PMFactory;
} else {
    guiFactory = new DefaultGUIFactory;
}
// Pass guiFactory to all subsystems — they never see a concrete class name

Step 6: Handle Singleton, Prototype, or Extensibility Concerns

ACTION: Apply one or more of the three standard implementation refinements based on the system's constraints.

WHY: The basic four-step structure above covers the standard case. The three refinements address recurring complications. Choosing the wrong refinement (or skipping one when it is needed) leads to: unnecessary multi-instantiation of factories (singleton concern), an explosion of ConcreteFactory subclasses when families multiply (prototype concern), or a brittle interface that breaks when new product types are added (extensibility concern).

Refinement A — Factories as Singletons

An application typically needs exactly one instance of each ConcreteFactory per product family. Multiple instances would allow different parts of the application to use different families simultaneously, which is precisely the co-usage violation the pattern prevents.

Apply the Singleton pattern to each ConcreteFactory class. The factory's construction is then controlled and the single instance is shared across all clients.

Refinement B — Prototype-based Factories (when families are many and similar)

The factory-method approach requires a new ConcreteFactory subclass for each product family. When many product families exist (or families differ only slightly), this produces a combinatorial number of factory subclasses.

The alternative: a single concrete factory initialized with prototype instances. The factory's Make method clones the appropriate prototype rather than calling a subclass-specific factory method:

"Smalltalk prototype-based factory"
make: partName
    ^ (partCatalog at: partName) copy

addPart: partTemplate named: partName
    partCatalog at: partName put: partTemplate

Creating an EnchantedMazeFactory requires no new class — only a different factory initialization:

createMazeFactory
    ^ (MazeFactory new
        addPart: Wall named: #wall;
        addPart: EnchantedRoom named: #room;
        addPart: DoorNeedingSpell named: #door;
        yourself)

Prefer the prototype approach when: (a) many product families exist, (b) families differ only in which concrete products they use, or (c) you need to create new families at runtime by composing existing prototypes.

Refinement C — Extensible Factory Interface

The standard AbstractFactory interface is closed: adding a new product type requires changing the interface and all ConcreteFactories. A more flexible (but less type-safe) alternative is a single parameterized Make method:

// Type-safe but closed
virtual ScrollBar* CreateScrollBar() = 0;
virtual Button*    CreateButton() = 0;

// Flexible but loses static type safety
virtual AbstractProduct* Make(const string& productKind) = 0;

The parameterized version needs only one method change when new product types are added, but products are returned as a common abstract type — clients must cast (or use dynamic typing). This trade-off is the classic extensibility vs. type safety tension.

Use the extensible form when: the product type set is known to grow, you are in a dynamically typed language (where the casting cost disappears), or the flexibility benefit outweighs the safety cost. Stick with the standard form when: the product set is stable, static type checking matters, and you want the compiler to catch misuse.

Step 7: Validate and Document Known Trade-offs

ACTION: Verify the implementation satisfies all invariants, then explicitly document the extensibility liability.

WHY: Two of the four consequences of Abstract Factory are benefits (isolation, easy exchange), one is a benefit-with-a-condition (consistency, which only holds if you never mix factories), and one is a genuine liability (supporting new product kinds is hard). Documenting the liability upfront prevents the team from discovering it painfully later when someone tries to add a new product type.

Validation checklist:

• [ ] No concrete product class names appear in client code (verify with grep)
• [ ] Every product type in the matrix has an AbstractProduct interface
• [ ] Every ConcreteFactory implements every AbstractProduct creation method
• [ ] Factory is initialized once, at application startup or configuration boundary
• [ ] If Singleton refinement was applied — factory construction is controlled
• [ ] If Prototype refinement was applied — prototype registry is populated before first use
• [ ] If Extensibility refinement was applied — all clients handle the downcast safely

Document the trade-off:

Inputs

• Existing code with scattered new ConcreteProduct(...) calls that need to be family-switched, OR
• A design description identifying: (a) product types, (b) product families, (c) the client that consumes products

Outputs

• abstract_factory.py (or .h/.cpp, .java, etc.) — AbstractFactory + AbstractProduct interfaces
• concrete_factories.py — one ConcreteFactory per family, with ConcreteProduct implementations
• Updated client code — factory-mediated, with all concrete class names removed

Key Principles

• The interface is the commitment — every product type your AbstractFactory declares is a permanent entry in the contract. Adding product types later is costly. Invest in completeness at design time rather than patching the interface repeatedly.

• One factory initialization point — the concrete factory should be chosen exactly once, at the application's configuration boundary. Allowing factory selection to spread through the codebase recreates the family-mixing problem the pattern solves.

• Consistency is structural, not conventional — the value of Abstract Factory over a naming convention ("always use Motif widgets together") is that the structure makes family mixing impossible. If clients can bypass the factory, the guarantee evaporates.

• Prototype over subclass when families multiply — factory-method-based AbstractFactory creates one ConcreteFactory subclass per product family. When families are many or differ only slightly, the prototype approach eliminates the subclass explosion without sacrificing the interface guarantee.

• The extensibility liability is real — Abstract Factory trades extensibility for consistency. The pattern is appropriate when the product type set is stable. If new product types are expected frequently, the parameterized Make interface or a different pattern (Prototype, Builder) may be more appropriate.

Examples

Example 1: Lexi GUIFactory — Look-and-Feel Portability

Scenario: Lexi, a document editor, must run on Motif, Presentation Manager, and Mac. Every widget creation call currently names a concrete class, making it impossible to switch look-and-feel at runtime or port to a new platform without auditing the entire codebase.

Trigger: "We need to support a new look-and-feel standard, but widgets are instantiated directly throughout the application."

Product matrix:

AbstractFactory interface:

class GUIFactory {
public:
    virtual ScrollBar* CreateScrollBar() = 0;
    virtual Button*    CreateButton()    = 0;
    virtual Menu*      CreateMenu()      = 0;
};

Runtime family selection at startup:

GUIFactory* guiFactory;
const char* styleName = getenv("LOOK_AND_FEEL");

if (strcmp(styleName, "Motif") == 0)
    guiFactory = new MotifFactory;
else if (strcmp(styleName, "Presentation_Manager") == 0)
    guiFactory = new PMFactory;
else
    guiFactory = new DefaultGUIFactory;

// guiFactory passed to all Application subsystems
// No subsystem ever imports or names MotifScrollBar, PMButton, etc.

Output: Adding Mac support requires a MacFactory + three MacProduct classes. Zero changes to application logic, layout code, or event handling. A MotifMenu can never appear beside a PMButton — the factory makes this impossible.

Example 2: MazeFactory — Swappable Maze Components

Scenario: A maze game hard-codes Room, Wall, and Door in its CreateMaze function. Adding enchanted mazes or bombed mazes requires forking CreateMaze for each variant — a maintenance problem.

Trigger: "Every new maze type requires duplicating the maze-building logic with different class names."

AbstractFactory (also acts as ConcreteFactory for the default case):

class MazeFactory {
public:
    virtual Maze* MakeMaze()  const { return new Maze; }
    virtual Wall* MakeWall()  const { return new Wall; }
    virtual Room* MakeRoom(int n) const { return new Room(n); }
    virtual Door* MakeDoor(Room* r1, Room* r2) const { return new Door(r1, r2); }
};

Client uses only factory calls — no concrete class names:

Maze* MazeGame::CreateMaze(MazeFactory& factory) {
    Maze* aMaze = factory.MakeMaze();
    Room* r1 = factory.MakeRoom(1);
    Room* r2 = factory.MakeRoom(2);
    Door* aDoor = factory.MakeDoor(r1, r2);

    aMaze->AddRoom(r1);
    aMaze->AddRoom(r2);
    r1->SetSide(North, factory.MakeWall());
    r1->SetSide(East, aDoor);
    r1->SetSide(South, factory.MakeWall());
    r1->SetSide(West, factory.MakeWall());
    // ...
    return aMaze;
}

ConcreteFactories override only the methods that differ:

class EnchantedMazeFactory : public MazeFactory {
public:
    Room* MakeRoom(int n) const override {
        return new EnchantedRoom(n, CastSpell());
    }
    Door* MakeDoor(Room* r1, Room* r2) const override {
        return new DoorNeedingSpell(r1, r2);
    }
protected:
    Spell* CastSpell() const;
};

class BombedMazeFactory : public MazeFactory {
public:
    Wall* MakeWall() const override { return new BombedWall; }
    Room* MakeRoom(int n) const override { return new RoomWithABomb(n); }
};

Usage — single factory swap changes the entire maze variant:

MazeGame game;
BombedMazeFactory factory;
game.CreateMaze(factory);  // builds a maze with bombs — zero changes to CreateMaze

Output: CreateMaze is written once. Supporting three maze variants requires three factory classes — none of which touch the maze-building algorithm. The Smalltalk prototype-based version creates EnchantedMazeFactory without a new class, by initializing a MazeFactory with different prototype instances for #room and #door.

Example 3: Database Abstraction Layer

Scenario: A backend application runs tests against SQLite and production against PostgreSQL. Connection, query builder, and transaction objects all vary by database. Currently the database type is conditionally checked in dozens of places.

Trigger: "We have if db == 'postgres' scattered everywhere — adding a MySQL test environment would require touching every one."

Product matrix:

AbstractFactory + client:

class DatabaseFactory(ABC):
    @abstractmethod
    def create_connection(self) -> Connection: ...

    @abstractmethod
    def create_query_builder(self) -> QueryBuilder: ...

    @abstractmethod
    def create_transaction(self) -> Transaction: ...

# Client receives factory — never imports Postgres or SQLite classes
class Repository:
    def __init__(self, factory: DatabaseFactory):
        self._conn = factory.create_connection()
        self._qb   = factory.create_query_builder()

    def find_by_id(self, id: int):
        query = self._qb.select("users").where("id", id).build()
        return self._conn.execute(query)

Test environment wiring:

# tests/conftest.py
factory = SQLiteFactory(":memory:")

# production
factory = PostgresFactory(os.environ["DATABASE_URL"])

repo = Repository(factory)

Output: Adding MySQL support is a MySQLFactory class and three concrete products. Zero changes to Repository, zero changes to test setup beyond adding a new factory option.

Reference Files

License

This skill is licensed under CC-BY-SA-4.0. Source: BookForge — Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.

Related BookForge Skills

Install related skills from ClawhHub:

• clawhub install bookforge-creational-pattern-selector

Or install the full book set from GitHub: bookforge-skills