Abstract Factory, Builder, and Factory Method — GoF Creational Patterns

This section covers the tail end of the Abstract Factory pattern (maze game variations and Smalltalk implementation), the complete Builder pattern (separating complex object construction from representation), and the beginning of the Factory Method pattern (deferring instantiation to subclasses). All three are creational patterns from the Gang of Four catalog that address different aspects of object creation flexibility.

Key Concepts

• Abstract Factory is commonly implemented as a collection of factory methods; the base factory can be concrete (acting as both AbstractFactory and ConcreteFactory), not just abstract
• Builder separates the *algorithm for constructing* a complex object from the *parts and assembly* — the Director drives the build process while the Builder defines the construction interface
• Builder constructs products step by step under the Director's control; the product is retrieved only when finished (contrast with Abstract Factory, which returns products immediately)
• Builder's build methods should be empty by default (not pure virtual), letting ConcreteBuilders override only the operations they care about
• Products built by different ConcreteBuilders typically share no common parent class — they differ too greatly in representation
• Factory Method defines an interface for creating an object but lets subclasses decide the concrete class — also known as Virtual Constructor
• Factory Method eliminates binding application-specific classes into framework code; the code deals only with the Product interface
• A potential disadvantage: clients might have to subclass Creator just to create a particular ConcreteProduct
• Factory Method connects parallel class hierarchies (e.g., Figure/Manipulator), localizing knowledge of which classes belong together
• Two major varieties of Factory Method: (1) abstract Creator with no default implementation, (2) concrete Creator with a default implementation
• Parameterized factory methods take a parameter identifying the kind of product to create, supporting multiple product types from a single method
• In Smalltalk, Abstract Factory can use a partCatalog dictionary mapping keys to classes, with a single make: method — swapping product families means changing the dictionary entries
• Downcasting from a base product type to a concrete subclass is safe only if the factory guarantees the concrete type; dynamically typed languages avoid this but risk run-time errors instead

Commands and Syntax

Builder pattern structure (C++):

// Abstract Builder with empty defaults
class MazeBuilder {
public:
    virtual void BuildMaze() { }
    virtual void BuildRoom(int room) { }
    virtual void BuildDoor(int roomFrom, int roomTo) { }
    virtual Maze* GetMaze() { return 0; }
protected:
    MazeBuilder();
};

// Director uses Builder interface — hides internal representation
Maze* MazeGame::CreateMaze(MazeBuilder& builder) {
    builder.BuildMaze();
    builder.BuildRoom(1);
    builder.BuildRoom(2);
    builder.BuildDoor(1, 2);
    return builder.GetMaze();
}

// Client usage
MazeGame game;
StandardMazeBuilder builder;
game.CreateMaze(builder);
Maze* maze = builder.GetMaze();

CountingMazeBuilder — Builder that doesn't create, only counts:

class CountingMazeBuilder : public MazeBuilder {
public:
    virtual void BuildRoom(int) { _rooms++; }
    virtual void BuildDoor(int, int) { _doors++; }
    void GetCounts(int& rooms, int& doors) const;
private:
    int _doors;
    int _rooms;
};

Smalltalk Abstract Factory with partCatalog:

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

make: partName
    ^ (partCatalog at: partName) new

Factory Method structure (C++):

// Creator declares factory method
class Application {
public:
    virtual Document* CreateDocument() = 0;
};

// ConcreteCreator overrides to return ConcreteProduct
class MyApplication : public Application {
public:
    Document* CreateDocument() override {
        return new MyDocument;
    }
};

Relationships

• Abstract Factory is often implemented *with* Factory Methods — a factory class containing one factory method per product type is the most common form
• Abstract Factory can alternatively be implemented using Prototype (cloning prototypes instead of calling constructors)
• A concrete factory is often a Singleton
• Builder vs Abstract Factory: Builder constructs step-by-step and returns the product as a final step; Abstract Factory returns products immediately and emphasizes families of related objects
• Composite is what the Builder often builds (tree structures, parse trees)
• Factory Method is used *within* Abstract Factory to implement each product creation method
• Factory Method connects parallel class hierarchies (e.g., Figure ↔ Manipulator), where each side has its own inheritance tree linked by factory methods
• Director (Builder) and Creator (Factory Method) both delegate object creation, but Director delegates to an external builder object while Creator delegates to its own subclasses

Exam-Relevant Points

• Builder constructs step by step; Abstract Factory returns products immediately — this is the primary distinguishing factor
• Builder's build methods are empty by default, not pure virtual — derived classes override only what they need
• Products from different ConcreteBuilders typically have no common parent class because representations differ too greatly
• The client retrieves the product from the Builder, not from the Director
• Factory Method's alternative name is Virtual Constructor
• Two varieties of Factory Method: abstract Creator (forces subclass implementation) vs. concrete Creator (provides default, subclasses override for flexibility)
• Factory Method disadvantage: may force clients to subclass Creator solely to create a specific product
• Abstract Factory can be both AbstractFactory and ConcreteFactory simultaneously (non-abstract base factory) for simple applications
• Parameterized factory methods use a parameter to select among multiple product types from a single method
• In Smalltalk, Abstract Factory uses a dictionary (partCatalog) mapping symbolic keys to classes — changing the family means swapping dictionary entries
• Known uses of Builder: ET++ RTF converter, Smalltalk-80's Parser/ProgramNodeBuilder, ClassBuilder, ByteCodeStream
• Known uses of Abstract Factory: InterViews (WidgetKit, DialogKit, LayoutKit), ET++ WindowSystem portability layer
• CountingMazeBuilder demonstrates that a Builder need not create any product at all — it can perform analysis (counting) using the same construction interface