Visitor Pattern, Creational Patterns Introduction, and Abstract Factory

This excerpt completes the Visitor pattern discussion from the Lexi document editor case study, summarizes all eight patterns applied in that case study, introduces the Creational Patterns category, and presents the Abstract Factory pattern in full detail — including intent, structure, consequences, implementation techniques, and a maze-building code example.

Key Concepts

• Visitor pattern generalizes analysis operations (spelling, hyphenation) by defining an Accept(Visitor&) method on elements and Visit<Element> methods on visitors — new analyses require only new Visitor subclasses, not changes to the element hierarchy
• Discretionary glyphs are Visitor-created objects inserted at hyphenation points that render as a hyphen only when they fall at a line break, otherwise invisible
• Visitor trade-off: stable element hierarchies benefit most; adding a new element subclass forces updates to every Visitor subclass
• Creational patterns abstract the instantiation process, making systems independent of how objects are created, composed, and represented
• Two recurring themes in creational patterns: (1) encapsulate knowledge of concrete classes, (2) hide how instances are created and assembled
• Abstract Factory provides an interface for creating families of related objects without specifying concrete classes (also known as "Kit")
• Abstract Factory isolates concrete classes — product class names appear only in the concrete factory implementation, never in client code
• Exchanging product families is trivial — change one concrete factory and the entire family switches atomically
• Consistency enforcement — using a single factory guarantees all products come from the same family (e.g., Motif button with Motif scrollbar)
• Adding new product kinds is difficult — requires changing the AbstractFactory interface and all subclasses (the pattern's main liability)

Commands and Syntax

Visitor accept/visit protocol:

class Visitor {
public:
    virtual void VisitCharacter(Character*) { }
    virtual void VisitRow(Row*) { }
    virtual void VisitImage(Image*) { }
};

// In each Glyph subclass:
void Character::Accept(Visitor& v) { v.VisitCharacter(this); }

Maze component hierarchy (creational patterns example):

enum Direction {North, South, East, West};

class MapSite {
public:
    virtual void Enter() = 0;
};

class Room : public MapSite {
public:
    Room(int roomNo);
    MapSite* GetSide(Direction) const;
    void SetSide(Direction, MapSite*);
    virtual void Enter();
private:
    MapSite* _sides[4];
    int _roomNumber;
};

Abstract Factory — MazeFactory:

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); }
};

Parameterized CreateMaze using Abstract Factory:

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);
    // ... remaining sides
    return aMaze;
}

Concrete factory via subclassing (EnchantedMazeFactory):

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

Prototype-based factory in Smalltalk:

make: partName
    ^ (partCatalog at: partName) copy

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

Relationships

• Visitor works with Composite (traverses composite structures) and Iterator (drives the traversal)
• Visitor can apply Strategy internally (e.g., swappable spelling algorithms)
• Abstract Factory often implemented as a Singleton (one factory per product family)
• Abstract Factory uses Factory Method internally (each Make* method is a factory method overridden by subclasses)
• Abstract Factory can alternatively use Prototype (clone prototypical products instead of subclassing)
• Creational patterns interrelate: Builder can use Abstract Factory or Prototype; Prototype can use Singleton
• The eight patterns in Lexi: Composite, Strategy, Decorator, Abstract Factory, Bridge, Command, Iterator, Visitor
• The five creational patterns are: Abstract Factory, Builder, Factory Method, Prototype, Singleton

Exam-Relevant Points

• Visitor's key question: "Which hierarchy changes more often?" Use Visitor when the element hierarchy is stable but analyses change frequently; avoid when new element types are added often
• Visitors can traverse any object structure (composites, sets, lists, DAGs) and work across unrelated class hierarchies
• Abstract Factory's four consequences: isolates concrete classes, easy family exchange, enforces product consistency, hard to add new product kinds
• Three implementation strategies for Abstract Factory: (1) factory methods in subclasses, (2) prototype-based cloning, (3) class-as-factory in languages with first-class classes
• Extensible factories use a parameterized Make operation — more flexible but loses type safety (client gets abstract base type back)
• Creational patterns shift emphasis from class inheritance to object composition for configuring behavior
• The hard-coded CreateMaze illustrates the core problem creational patterns solve: inflexibility from explicit concrete class references
• Each creational pattern removes hard-coding differently: Factory Method (virtual functions), Abstract Factory (factory parameter), Builder (builder parameter), Prototype (clone prototypical objects)