Visitor Pattern

Also Known As

TL;DR

Explanation

The Visitor pattern uses double dispatch: the object calls accept(visitor), which calls visitor.visit(this). This allows adding new operations to a stable class hierarchy by writing new Visitor classes rather than adding methods to each node. Common uses: abstract syntax tree traversal, serialisation to different formats, static analysis tools, and document export. The trade-off: adding a new node type requires updating all existing visitors.

Common Misconception

Why It Matters

Common Mistakes

• Using Visitor when the class hierarchy changes frequently — each new class requires updating all visitors, which is more painful than adding a method to each class.
• Not defining a VisitorInterface — without it, the pattern provides no type safety.
• Confusing Visitor (new operations, stable classes) with Strategy (interchangeable algorithms, single class).
• Implementing Visitor for simple trees where a recursive method on each node is simpler.

Code Examples

// Without visitor — adding export requires modifying every node:
class TextNode {
    public function toHtml(): string { /* ... */ }
    public function toPdf(): string { /* ... */ }  // Must add to every node class
    public function toMarkdown(): string { /* ... */ } // Keeps growing
}

// Visitor — add new export format without touching node classes:
interface NodeVisitor {
    public function visitText(TextNode $node): string;
    public function visitImage(ImageNode $node): string;
}

class TextNode {
    public function accept(NodeVisitor $v): string { return $v->visitText($this); }
}

class MarkdownExporter implements NodeVisitor {
    public function visitText(TextNode $n): string { return $n->content; }
    public function visitImage(ImageNode $n): string { return "![]({$n->src})"; }
}

References

• ↗ https://refactoring.guru/design-patterns/visitor

Tags

Related Terms