System Design (LLD)Visitor Pattern

Visitor Pattern: Adding Operations Without Modifying Classes

LevelIntermediate

Duration60 mins

TopicVisitor Pattern

3 / 4

When to Use Visitor

The Visitor Decision

The Visitor pattern is powerful—but it's not always the right choice. It introduces complexity and makes certain kinds of changes harder. Knowing when to apply Visitor (and when to avoid it) separates journeyman programmers from design pattern masters.

This page provides a comprehensive decision framework for evaluating when the Visitor pattern is the right tool for your specific situation.

What You Will Learn

By the end of this page, you will have clear criteria for deciding when to use the Visitor pattern. You'll understand the costs and benefits, know the warning signs that indicate Visitor is the wrong choice, and be able to evaluate trade-offs in real scenarios.

Prerequisites for Visitor Pattern

The Visitor pattern isn't universally applicable. It requires specific conditions to be worth the complexity it introduces. Before considering Visitor, verify these prerequisites are met.

Essential Prerequisites

•Well-Defined Element Interface: You have a clear set of element types with a common interface. The elements should already have a natural operations or query needs via a common API.
•Stable Type Hierarchy: The element types are unlikely to change frequently. Adding new element types requires modifying all visitors—if types change often, Visitor creates maintenance burden.
•Multiple Operations Needed: You need (or anticipate needing) multiple different operations on the same element structure. If you only need one operation, traditional polymorphism is simpler.
•Operations Are Conceptually Separate: The operations are logically distinct and shouldn't be tightly coupled with the elements themselves. PDF export and word count are separate concerns.
•Need for Independent Development: Different operations may be developed by different teams or deployed independently. Visitors enable this separation.

The Critical Question

Ask yourself: What changes more often—element types or operations?

If element types change frequently, avoid Visitor. The pattern optimizes for stable types and changing operations. Get this backwards, and you'll be modifying many visitors every time you add a type.

Prerequisites Assessment
Prerequisite	Strong Signal FOR Visitor	Warning Signal AGAINST Visitor
Type Stability	Types unchanged for 1+ years	New types added monthly or more often
Operation Volume	5+ distinct operations needed	Only 1-2 operations needed
Structure Complexity	Complex tree/graph structures	Simple flat collections
Team Structure	Multiple teams add operations	Single team owns everything
Deployment Model	Operations deployed independently	Monolithic deployment

Ideal Use Cases

Some problem domains are natural fits for the Visitor pattern. In these contexts, the pattern's trade-offs align perfectly with the domain's characteristics.

Canonical Use Cases

•Compilers and Interpreters: ASTs have fixed node types (expressions, statements, declarations) but need many passes: parsing, type checking, optimization, code generation, error reporting, pretty printing, IDE features.
•Document Object Models: DOMs have stable element types (paragraph, heading, list, table) but need many operations: rendering to formats, statistics, validation, transformation, accessibility checking.
•GUI Widget Hierarchies: Widget types stabilize early (button, text field, container), but operations grow: rendering, layout, theming, serialization, accessibility, animation.
•File System Operations: File system node types are fixed (file, directory, symlink), but operations are numerous: size calculation, copy, search, backup, sync, permission check.
•Static Analysis Tools: Code structure nodes are language-defined, but analysis passes multiply: lint rules, security checks, complexity metrics, dead code detection.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// A programming language's AST is the classic Visitor example.
// Node types are defined by the language spec - they change rarely.
// Operations multiply as the compiler/IDE matures.
 
interface ASTVisitor<R> {
    // Expressions
    visitLiteral(node: Literal): R;
    visitIdentifier(node: Identifier): R;
    visitBinaryExpression(node: BinaryExpression): R;
    visitCallExpression(node: CallExpression): R;
    visitArrowFunction(node: ArrowFunction): R;
    
    // Statements
    visitVariableDeclaration(node: VariableDeclaration): R;
    visitIfStatement(node: IfStatement): R;
    visitForStatement(node: ForStatement): R;
    visitReturnStatement(node: ReturnStatement): R;
    
    // Declarations
    visitFunctionDeclaration(node: FunctionDeclaration): R;
    visitClassDeclaration(node: ClassDeclaration): R;
    visitInterfaceDeclaration(node: InterfaceDeclaration): R;
}
 
// These 15 node types might not change for years.
// But the compiler/IDE adds new operations constantly:
 
class TypeChecker implements ASTVisitor<Type> { /* ... */ }
class Interpreter implements ASTVisitor<RuntimeValue> { /* ... */ }
class JavaScriptEmitter implements ASTVisitor<string> { /* ... */ }
class WasmEmitter implements ASTVisitor<WasmInstruction[]> { /* ... */ }
class PrettyPrinter implements ASTVisitor<string> { /* ... */ }
class Minifier implements ASTVisitor<string> { /* ... */ }
class ConstantFolder implements ASTVisitor<ASTNode> { /* ... */ }
class DeadCodeFinder implements ASTVisitor<Diagnostic[]> { /* ... */ }
class ReferenceFinder implements ASTVisitor<Reference[]> { /* ... */ }
class Renamer implements ASTVisitor<ASTNode> { /* ... */ }
class ComplexityCalculator implements ASTVisitor<number> { /* ... */ }
class SecurityLinter implements ASTVisitor<Vulnerability[]> { /* ... */ }
 
// 12 visitors, each encapsulating one concern.
// Each can be developed, tested, and versioned independently.
// Adding visitor #13 requires zero changes to AST node classes.

TypeScript's Actual Architecture

TypeScript's compiler uses the Visitor pattern extensively. The AST node types are defined in the language spec and change slowly (maybe a few additions per major version). But analysis passes, transformations, and emit targets are added frequently. The Visitor pattern is why the TypeScript team can add features without rewriting the core node types.

When NOT to Use Visitor

The Visitor pattern introduces significant complexity. In many situations, simpler alternatives are better. Recognizing these situations saves you from over-engineering.

Avoid Visitor When...

•Type Hierarchy Changes Frequently: If you add new element types regularly, every visitor becomes a breaking change. New type = modify all visitors. This is Visitor's Achilles heel.
•Only One or Two Operations Needed: If you only need one operation, regular polymorphism is simpler. Visitor's overhead isn't justified for small operation counts.
•Operations Need Element's Private State: Visitors access elements through their public interface. If operations need private internals, you'll either break encapsulation or add many accessor methods.
•Simple Flat Structures: Visitor shines with complex trees/graphs. For simple collections, a loop or map/filter is clearer and simpler.
•Language Has Pattern Matching: Languages with native pattern matching or discriminated unions (Rust, Haskell, OCaml, Scala) often don't need Visitor—the language provides better solutions.
•Team Isn't Familiar with Pattern: Visitor is complex. If your team doesn't know it well and won't benefit from learning it, simpler approaches may be better despite being less elegant.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// Scenario: Payment processing with one main operation
 
// ❌ Visitor is overkill here
interface PaymentVisitor {
    visitCreditCard(payment: CreditCardPayment): void;
    visitPayPal(payment: PayPalPayment): void;
    visitBankTransfer(payment: BankTransferPayment): void;
}
 
// If we only process payments, regular polymorphism is cleaner:
 
// ✅ Simple polymorphism
interface Payment {
    process(): ProcessingResult;
    validate(): ValidationResult;
}
 
class CreditCardPayment implements Payment {
    process(): ProcessingResult {
        return this.chargeCard();
    }
    
    validate(): ValidationResult {
        return this.checkLuhn() && this.checkExpiry();
    }
}
 
class PayPalPayment implements Payment {
    process(): ProcessingResult {
        return this.initiatePayPalTransaction();
    }
    
    validate(): ValidationResult {
        return this.verifyPayPalAccount();
    }
}
 
// If payment types change (new crypto payments, buy-now-pay-later),
// adding a new type is trivial with polymorphism,
// but would require updating all visitors with Visitor pattern.

The Over-Engineering Trap

Don't use Visitor because it's "clever" or "elegant."

Visitor adds indirection, makes code harder to follow, and creates coupling between all visitors and the element type set. Only use it when the benefits (adding operations without changing elements) outweigh these costs. If in doubt, start with simpler approaches and refactor to Visitor if needed.

Visitor vs Alternatives

Before committing to Visitor, consider alternatives that might solve your problem with less complexity.

Visitor Pattern vs Alternative Approaches
Approach	When to Prefer Over Visitor	Trade-off
Regular Polymorphism	Types change more than operations; few operations	Hard to add operations, easy to add types
Discriminated Unions + Switch	Language supports it; exhaustiveness checking; types are stable	Less OOP-idiomatic; no encapsulation
Type Classes/Traits	Language supports it (Haskell, Rust, Scala)	Language-specific; learning curve
Command Pattern	Operations are queued, undoable, or serialized	Less suited for structure traversal
Extension Methods	Language supports it; operations don't need double dispatch	Single dispatch only; can't handle visitor type variations

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// TypeScript's discriminated unions provide exhaustiveness checking
// This is often simpler than Visitor for TypeScript/JavaScript
 
type Expression = 
    | { kind: 'number'; value: number }
    | { kind: 'binary'; left: Expression; op: string; right: Expression }
    | { kind: 'variable'; name: string }
    | { kind: 'call'; fn: string; args: Expression[] };
 
// Operations are just functions with exhaustive switches
function evaluate(expr: Expression, env: Map<string, number>): number {
    switch (expr.kind) {
        case 'number':
            return expr.value;
        case 'binary':
            const left = evaluate(expr.left, env);
            const right = evaluate(expr.right, env);
            switch (expr.op) {
                case '+': return left + right;
                case '*': return left * right;
                // ...
            }
        case 'variable':
            return env.get(expr.name) ?? 0;
        case 'call':
            // ... function call handling
    }
}
 
function prettyPrint(expr: Expression): string {
    switch (expr.kind) {
        case 'number':
            return expr.value.toString();
        case 'binary':
            return `(${prettyPrint(expr.left)} ${expr.op} ${prettyPrint(expr.right)})`;
        case 'variable':
            return expr.name;
        case 'call':
            return `${expr.fn}(${expr.args.map(prettyPrint).join(', ')})`;
    }
}
 
// ✅ Advantages over Visitor:
// - Simpler, more direct code
// - TypeScript checks exhaustiveness
// - No double dispatch complexity
// - Adding operations = adding functions
 
// ❌ Disadvantages vs Visitor:
// - Adding new kind requires updating ALL switch statements
// - No inheritance between expression types
// - Can't substitute different implementations (all in one function)
// - Less suited for stateful operations

Language Matters

The right choice depends on your language. In Java, Visitor is often necessary. In TypeScript, discriminated unions often work better. In Rust, pattern matching is superior. In Kotlin/Scala, sealed classes with when expressions provide exhaustiveness. Know your language's idioms.

Cost-Benefit Analysis

Every design pattern has costs. Understanding Visitor's specific costs helps you make informed decisions.

Benefits

•Add operations without changing elements
•Operations centralized in one class each
•Operations can maintain state across visits
•Double dispatch without instanceof
•Can version operations independently
•Enables cross-cutting operations

Costs

•Adding types requires changing all visitors
•Double dispatch adds cognitive complexity
•Breaks encapsulation - elements expose internals
•Visitor accumulates methods as types grow
•Indirection makes debugging harder
•Less intuitive than polymorphism

Quantifying the Trade-off

Let's make the trade-off concrete. Suppose you have:

T element types
O operations

Action	Without Visitor	With Visitor
Add new operation	Modify T files	Create 1 new visitor class
Add new type	Create 1 new class	Create 1 class + modify O visitors

Visitor wins when O grows faster than T. If you expect to add many operations but few types, Visitor pays off. If types grow faster than operations, avoid Visitor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Example Scenario Analysis:
 
Setup:
- 10 element types (T = 10)
- Currently 3 operations (O = 3)
- Expected: 5 more operations, 1 more type over next year
 
WITHOUT Visitor (operations in element classes):
- Add 5 operations: 5 ops × 10 types = 50 method additions (across 10 files)
- Add 1 type: 1 new class file with 8 methods (3 existing + 5 new ops)
 
WITH Visitor:
- Initial setup: 10 accept methods + 3 visitors with 10 methods each = 40 methods
- Add 5 operations: 5 new visitor classes, each with 10 methods = 50 methods (in 5 new files)
- Add 1 type: 1 new class + update 8 visitors = 9 file changes
 
Comparison:
- Total new methods: Similar (~50)
- File changes for operations: Visitor wins (1 file per op vs 10)
- File changes for types: Polymorphism wins (1 file vs 9)
- But wait: files change less frequently with Visitor for our expected trajectory!
 
Verdict for this scenario: 
→ Visitor pattern is worth it
→ 5:1 ratio of new operations to new types favors Visitor

Visitor Pattern Smells

Even when Visitor is the right choice initially, problems can emerge. Watch for these warning signs that indicate your Visitor implementation is becoming problematic.

Warning Signs in Existing Visitor Implementations

•Visitor Interface Explosion: The visitor interface has 50+ methods. This suggests too many element types—consider grouping related types or questioning whether all types need visitor support.
•Mostly Empty Implementations: Most visitor methods are empty or default. This suggests the pattern is overkill—not all operations need all types. Consider partial visitor interfaces.
•Frequent Type Additions: You're adding new element types monthly, and updating all visitors is painful. The stability assumption is violated—reconsider the pattern.
•Accessor Method Proliferation: Elements have dozens of getters just for visitor access. This indicates broken encapsulation—consider whether visitors need all this data.
•Circular Dependencies: Visitors depend on elements, and elements depend on visitor interface. This creates compile-time coupling issues—consider interface segregation.
•Visitor Doing Too Much: A single visitor class has become a god class. Split into focused visitors with composition.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ Smell: Most visit methods are empty
 
class HeadingExtractor implements DocumentVisitor {
    private headings: Heading[] = [];
    
    visitParagraph(p: Paragraph): void { /* empty */ }
    visitImage(i: Image): void { /* empty */ }
    visitTable(t: Table): void { /* empty */ }
    visitCodeBlock(c: CodeBlock): void { /* empty */ }
    visitQuote(q: Quote): void { /* empty */ }
    visitHorizontalRule(h: HorizontalRule): void { /* empty */ }
    visitFootnote(f: Footnote): void { /* empty */ }
    visitLink(l: Link): void { /* empty */ }
    visitEmphasis(e: Emphasis): void { /* empty */ }
    // ... 10 more empty methods
    
    visitHeading(h: Heading): void {
        this.headings.push(h);  // Only this one does anything!
    }
    
    getHeadings(): Heading[] {
        return this.headings;
    }
}
 
// This suggests one of:
// 1. Too many element types in the visitor interface
// 2. This particular operation doesn't need full visitor machinery
// 3. Consider a filtered / targeted approach instead
 
// ✅ Better: Direct filtering without visitor
function extractHeadings(elements: DocumentElement[]): Heading[] {
    return elements.filter((e): e is Heading => e instanceof Heading);
}
 
// Or: Partial visitor with defaults
class BaseVisitor implements DocumentVisitor {
    visitParagraph(p: Paragraph): void { }
    visitImage(i: Image): void { }
    // ... all empty by default
}
 
class HeadingExtractor extends BaseVisitor {
    private headings: Heading[] = [];
    
    override visitHeading(h: Heading): void {
        this.headings.push(h);
    }
}

Decision Framework

Use this decision tree to determine if the Visitor pattern is right for your situation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
VISITOR PATTERN DECISION TREE
 
START: Do you have a class hierarchy with multiple types?
  │
  ├─ NO ──► STOP. Visitor is for object structures. Consider simpler patterns.
  │
  └─ YES ──► Are the element types stable (unlikely to change frequently)?
              │
              ├─ NO ──► AVOID VISITOR. Use polymorphism.
              │         Adding types will be painful with Visitor.
              │
              └─ YES ──► Do you need multiple operations on these types?
                          │
                          ├─ NO (1-2 operations) ──► AVOID VISITOR.
                          │                          Simple polymorphism is cleaner.
                          │
                          └─ YES ──► Do operations need to be added frequently?
                                      │
                                      ├─ NO ──► CONSIDER alternatives first.
                                      │         Visitor complexity may not be justified.
                                      │
                                      └─ YES ──► Do operations need to be 
                                                  developed/deployed independently?
                                                  │
                                                  ├─ NO ──► EVALUATE carefully.
                                                  │         Visitor may still not be worth it.
                                                  │
                                                  └─ YES ──► Does your language lack 
                                                              pattern matching / sealed types?
                                                              │
                                                              ├─ Has good pattern matching
                                                              │   (Rust, Kotlin, Scala)
                                                              │   ──► Use language features
                                                              │
                                                              └─ No pattern matching
                                                                  (Java, TypeScript)
                                                                  │
                                                                  └─► ✅ USE VISITOR PATTERN

Quick Decision Matrix
Criterion	Points FOR Visitor	Points AGAINST Visitor
Type stability	Types stable 1+ years (+3)	New types monthly (-5)
Operation count	5+ operations (+2)	1-2 operations (-3)
Operation growth	Expect 3+ new ops/year (+3)	Operations stable (-2)
Team separation	Different teams for ops (+2)	Single team (-1)
Deployment model	Independent op deployment (+2)	Monolith (-1)
Language	Java/C#/TypeScript (+1)	Rust/Kotlin/Scala (-2)

Scoring Your Situation

Add up the points from the matrix:

+8 or higher: Visitor is strongly recommended
+3 to +7: Visitor is worth considering
-2 to +2: Borderline—try simpler approaches first
-3 or lower: Avoid Visitor—use alternatives

Summary

Let's consolidate the decision criteria for the Visitor pattern:

Key Takeaways

•Use Visitor when types are stable and operations grow: It optimizes for adding operations, not types.
•Avoid Visitor when types change frequently: Every new type means updating every visitor.
•Consider alternatives first: Polymorphism, discriminated unions, pattern matching may be simpler.
•Watch for smells: Explosion of visit methods, mostly-empty visitors, frequent type additions.
•Use the decision framework: Evaluate your specific situation rather than applying patterns blindly.
•Language matters: Some languages have better built-in solutions than the Visitor pattern.

Page Complete

You now have a comprehensive framework for deciding when to use the Visitor pattern. You understand the prerequisites, ideal use cases, warning signs, costs vs benefits, and decision criteria. Next, we'll explore real-world use cases and practical examples of the Visitor pattern in action.

3 / 4

Loading learning content...

System Design (LLD)Visitor Pattern

Visitor Pattern: Adding Operations Without Modifying Classes

LevelIntermediate

Duration60 mins

TopicVisitor Pattern

3 / 4

When to Use Visitor

The Visitor Decision

This page provides a comprehensive decision framework for evaluating when the Visitor pattern is the right tool for your specific situation.

What You Will Learn

Prerequisites for Visitor Pattern

The Visitor pattern isn't universally applicable. It requires specific conditions to be worth the complexity it introduces. Before considering Visitor, verify these prerequisites are met.

Essential Prerequisites

•Well-Defined Element Interface: You have a clear set of element types with a common interface. The elements should already have a natural operations or query needs via a common API.
•Stable Type Hierarchy: The element types are unlikely to change frequently. Adding new element types requires modifying all visitors—if types change often, Visitor creates maintenance burden.
•Multiple Operations Needed: You need (or anticipate needing) multiple different operations on the same element structure. If you only need one operation, traditional polymorphism is simpler.
•Operations Are Conceptually Separate: The operations are logically distinct and shouldn't be tightly coupled with the elements themselves. PDF export and word count are separate concerns.
•Need for Independent Development: Different operations may be developed by different teams or deployed independently. Visitors enable this separation.

The Critical Question

Ask yourself: What changes more often—element types or operations?

If element types change frequently, avoid Visitor. The pattern optimizes for stable types and changing operations. Get this backwards, and you'll be modifying many visitors every time you add a type.

Prerequisites Assessment
Prerequisite	Strong Signal FOR Visitor	Warning Signal AGAINST Visitor
Type Stability	Types unchanged for 1+ years	New types added monthly or more often
Operation Volume	5+ distinct operations needed	Only 1-2 operations needed
Structure Complexity	Complex tree/graph structures	Simple flat collections
Team Structure	Multiple teams add operations	Single team owns everything
Deployment Model	Operations deployed independently	Monolithic deployment

Ideal Use Cases

Some problem domains are natural fits for the Visitor pattern. In these contexts, the pattern's trade-offs align perfectly with the domain's characteristics.

Canonical Use Cases

•Compilers and Interpreters: ASTs have fixed node types (expressions, statements, declarations) but need many passes: parsing, type checking, optimization, code generation, error reporting, pretty printing, IDE features.
•Document Object Models: DOMs have stable element types (paragraph, heading, list, table) but need many operations: rendering to formats, statistics, validation, transformation, accessibility checking.
•GUI Widget Hierarchies: Widget types stabilize early (button, text field, container), but operations grow: rendering, layout, theming, serialization, accessibility, animation.
•File System Operations: File system node types are fixed (file, directory, symlink), but operations are numerous: size calculation, copy, search, backup, sync, permission check.
•Static Analysis Tools: Code structure nodes are language-defined, but analysis passes multiply: lint rules, security checks, complexity metrics, dead code detection.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// A programming language's AST is the classic Visitor example.
// Node types are defined by the language spec - they change rarely.
// Operations multiply as the compiler/IDE matures.
 
interface ASTVisitor<R> {
    // Expressions
    visitLiteral(node: Literal): R;
    visitIdentifier(node: Identifier): R;
    visitBinaryExpression(node: BinaryExpression): R;
    visitCallExpression(node: CallExpression): R;
    visitArrowFunction(node: ArrowFunction): R;
    
    // Statements
    visitVariableDeclaration(node: VariableDeclaration): R;
    visitIfStatement(node: IfStatement): R;
    visitForStatement(node: ForStatement): R;
    visitReturnStatement(node: ReturnStatement): R;
    
    // Declarations
    visitFunctionDeclaration(node: FunctionDeclaration): R;
    visitClassDeclaration(node: ClassDeclaration): R;
    visitInterfaceDeclaration(node: InterfaceDeclaration): R;
}
 
// These 15 node types might not change for years.
// But the compiler/IDE adds new operations constantly:
 
class TypeChecker implements ASTVisitor<Type> { /* ... */ }
class Interpreter implements ASTVisitor<RuntimeValue> { /* ... */ }
class JavaScriptEmitter implements ASTVisitor<string> { /* ... */ }
class WasmEmitter implements ASTVisitor<WasmInstruction[]> { /* ... */ }
class PrettyPrinter implements ASTVisitor<string> { /* ... */ }
class Minifier implements ASTVisitor<string> { /* ... */ }
class ConstantFolder implements ASTVisitor<ASTNode> { /* ... */ }
class DeadCodeFinder implements ASTVisitor<Diagnostic[]> { /* ... */ }
class ReferenceFinder implements ASTVisitor<Reference[]> { /* ... */ }
class Renamer implements ASTVisitor<ASTNode> { /* ... */ }
class ComplexityCalculator implements ASTVisitor<number> { /* ... */ }
class SecurityLinter implements ASTVisitor<Vulnerability[]> { /* ... */ }
 
// 12 visitors, each encapsulating one concern.
// Each can be developed, tested, and versioned independently.
// Adding visitor #13 requires zero changes to AST node classes.

TypeScript's Actual Architecture

When NOT to Use Visitor

The Visitor pattern introduces significant complexity. In many situations, simpler alternatives are better. Recognizing these situations saves you from over-engineering.

Avoid Visitor When...

•Type Hierarchy Changes Frequently: If you add new element types regularly, every visitor becomes a breaking change. New type = modify all visitors. This is Visitor's Achilles heel.
•Only One or Two Operations Needed: If you only need one operation, regular polymorphism is simpler. Visitor's overhead isn't justified for small operation counts.
•Operations Need Element's Private State: Visitors access elements through their public interface. If operations need private internals, you'll either break encapsulation or add many accessor methods.
•Simple Flat Structures: Visitor shines with complex trees/graphs. For simple collections, a loop or map/filter is clearer and simpler.
•Language Has Pattern Matching: Languages with native pattern matching or discriminated unions (Rust, Haskell, OCaml, Scala) often don't need Visitor—the language provides better solutions.
•Team Isn't Familiar with Pattern: Visitor is complex. If your team doesn't know it well and won't benefit from learning it, simpler approaches may be better despite being less elegant.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// Scenario: Payment processing with one main operation
 
// ❌ Visitor is overkill here
interface PaymentVisitor {
    visitCreditCard(payment: CreditCardPayment): void;
    visitPayPal(payment: PayPalPayment): void;
    visitBankTransfer(payment: BankTransferPayment): void;
}
 
// If we only process payments, regular polymorphism is cleaner:
 
// ✅ Simple polymorphism
interface Payment {
    process(): ProcessingResult;
    validate(): ValidationResult;
}
 
class CreditCardPayment implements Payment {
    process(): ProcessingResult {
        return this.chargeCard();
    }
    
    validate(): ValidationResult {
        return this.checkLuhn() && this.checkExpiry();
    }
}
 
class PayPalPayment implements Payment {
    process(): ProcessingResult {
        return this.initiatePayPalTransaction();
    }
    
    validate(): ValidationResult {
        return this.verifyPayPalAccount();
    }
}
 
// If payment types change (new crypto payments, buy-now-pay-later),
// adding a new type is trivial with polymorphism,
// but would require updating all visitors with Visitor pattern.

The Over-Engineering Trap

Don't use Visitor because it's "clever" or "elegant."

Visitor vs Alternatives

Before committing to Visitor, consider alternatives that might solve your problem with less complexity.

Visitor Pattern vs Alternative Approaches
Approach	When to Prefer Over Visitor	Trade-off
Regular Polymorphism	Types change more than operations; few operations	Hard to add operations, easy to add types
Discriminated Unions + Switch	Language supports it; exhaustiveness checking; types are stable	Less OOP-idiomatic; no encapsulation
Type Classes/Traits	Language supports it (Haskell, Rust, Scala)	Language-specific; learning curve
Command Pattern	Operations are queued, undoable, or serialized	Less suited for structure traversal
Extension Methods	Language supports it; operations don't need double dispatch	Single dispatch only; can't handle visitor type variations

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// TypeScript's discriminated unions provide exhaustiveness checking
// This is often simpler than Visitor for TypeScript/JavaScript
 
type Expression = 
    | { kind: 'number'; value: number }
    | { kind: 'binary'; left: Expression; op: string; right: Expression }
    | { kind: 'variable'; name: string }
    | { kind: 'call'; fn: string; args: Expression[] };
 
// Operations are just functions with exhaustive switches
function evaluate(expr: Expression, env: Map<string, number>): number {
    switch (expr.kind) {
        case 'number':
            return expr.value;
        case 'binary':
            const left = evaluate(expr.left, env);
            const right = evaluate(expr.right, env);
            switch (expr.op) {
                case '+': return left + right;
                case '*': return left * right;
                // ...
            }
        case 'variable':
            return env.get(expr.name) ?? 0;
        case 'call':
            // ... function call handling
    }
}
 
function prettyPrint(expr: Expression): string {
    switch (expr.kind) {
        case 'number':
            return expr.value.toString();
        case 'binary':
            return `(${prettyPrint(expr.left)} ${expr.op} ${prettyPrint(expr.right)})`;
        case 'variable':
            return expr.name;
        case 'call':
            return `${expr.fn}(${expr.args.map(prettyPrint).join(', ')})`;
    }
}
 
// ✅ Advantages over Visitor:
// - Simpler, more direct code
// - TypeScript checks exhaustiveness
// - No double dispatch complexity
// - Adding operations = adding functions
 
// ❌ Disadvantages vs Visitor:
// - Adding new kind requires updating ALL switch statements
// - No inheritance between expression types
// - Can't substitute different implementations (all in one function)
// - Less suited for stateful operations

Language Matters

Cost-Benefit Analysis

Every design pattern has costs. Understanding Visitor's specific costs helps you make informed decisions.

Benefits

•Add operations without changing elements
•Operations centralized in one class each
•Operations can maintain state across visits
•Double dispatch without instanceof
•Can version operations independently
•Enables cross-cutting operations

Costs

•Adding types requires changing all visitors
•Double dispatch adds cognitive complexity
•Breaks encapsulation - elements expose internals
•Visitor accumulates methods as types grow
•Indirection makes debugging harder
•Less intuitive than polymorphism

Quantifying the Trade-off

Let's make the trade-off concrete. Suppose you have:

T element types
O operations

Action	Without Visitor	With Visitor
Add new operation	Modify T files	Create 1 new visitor class
Add new type	Create 1 new class	Create 1 class + modify O visitors

Visitor wins when O grows faster than T. If you expect to add many operations but few types, Visitor pays off. If types grow faster than operations, avoid Visitor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Example Scenario Analysis:
 
Setup:
- 10 element types (T = 10)
- Currently 3 operations (O = 3)
- Expected: 5 more operations, 1 more type over next year
 
WITHOUT Visitor (operations in element classes):
- Add 5 operations: 5 ops × 10 types = 50 method additions (across 10 files)
- Add 1 type: 1 new class file with 8 methods (3 existing + 5 new ops)
 
WITH Visitor:
- Initial setup: 10 accept methods + 3 visitors with 10 methods each = 40 methods
- Add 5 operations: 5 new visitor classes, each with 10 methods = 50 methods (in 5 new files)
- Add 1 type: 1 new class + update 8 visitors = 9 file changes
 
Comparison:
- Total new methods: Similar (~50)
- File changes for operations: Visitor wins (1 file per op vs 10)
- File changes for types: Polymorphism wins (1 file vs 9)
- But wait: files change less frequently with Visitor for our expected trajectory!
 
Verdict for this scenario: 
→ Visitor pattern is worth it
→ 5:1 ratio of new operations to new types favors Visitor

Visitor Pattern Smells

Even when Visitor is the right choice initially, problems can emerge. Watch for these warning signs that indicate your Visitor implementation is becoming problematic.

Warning Signs in Existing Visitor Implementations

•Visitor Interface Explosion: The visitor interface has 50+ methods. This suggests too many element types—consider grouping related types or questioning whether all types need visitor support.
•Mostly Empty Implementations: Most visitor methods are empty or default. This suggests the pattern is overkill—not all operations need all types. Consider partial visitor interfaces.
•Frequent Type Additions: You're adding new element types monthly, and updating all visitors is painful. The stability assumption is violated—reconsider the pattern.
•Accessor Method Proliferation: Elements have dozens of getters just for visitor access. This indicates broken encapsulation—consider whether visitors need all this data.
•Circular Dependencies: Visitors depend on elements, and elements depend on visitor interface. This creates compile-time coupling issues—consider interface segregation.
•Visitor Doing Too Much: A single visitor class has become a god class. Split into focused visitors with composition.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ Smell: Most visit methods are empty
 
class HeadingExtractor implements DocumentVisitor {
    private headings: Heading[] = [];
    
    visitParagraph(p: Paragraph): void { /* empty */ }
    visitImage(i: Image): void { /* empty */ }
    visitTable(t: Table): void { /* empty */ }
    visitCodeBlock(c: CodeBlock): void { /* empty */ }
    visitQuote(q: Quote): void { /* empty */ }
    visitHorizontalRule(h: HorizontalRule): void { /* empty */ }
    visitFootnote(f: Footnote): void { /* empty */ }
    visitLink(l: Link): void { /* empty */ }
    visitEmphasis(e: Emphasis): void { /* empty */ }
    // ... 10 more empty methods
    
    visitHeading(h: Heading): void {
        this.headings.push(h);  // Only this one does anything!
    }
    
    getHeadings(): Heading[] {
        return this.headings;
    }
}
 
// This suggests one of:
// 1. Too many element types in the visitor interface
// 2. This particular operation doesn't need full visitor machinery
// 3. Consider a filtered / targeted approach instead
 
// ✅ Better: Direct filtering without visitor
function extractHeadings(elements: DocumentElement[]): Heading[] {
    return elements.filter((e): e is Heading => e instanceof Heading);
}
 
// Or: Partial visitor with defaults
class BaseVisitor implements DocumentVisitor {
    visitParagraph(p: Paragraph): void { }
    visitImage(i: Image): void { }
    // ... all empty by default
}
 
class HeadingExtractor extends BaseVisitor {
    private headings: Heading[] = [];
    
    override visitHeading(h: Heading): void {
        this.headings.push(h);
    }
}

Decision Framework

Use this decision tree to determine if the Visitor pattern is right for your situation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
VISITOR PATTERN DECISION TREE
 
START: Do you have a class hierarchy with multiple types?
  │
  ├─ NO ──► STOP. Visitor is for object structures. Consider simpler patterns.
  │
  └─ YES ──► Are the element types stable (unlikely to change frequently)?
              │
              ├─ NO ──► AVOID VISITOR. Use polymorphism.
              │         Adding types will be painful with Visitor.
              │
              └─ YES ──► Do you need multiple operations on these types?
                          │
                          ├─ NO (1-2 operations) ──► AVOID VISITOR.
                          │                          Simple polymorphism is cleaner.
                          │
                          └─ YES ──► Do operations need to be added frequently?
                                      │
                                      ├─ NO ──► CONSIDER alternatives first.
                                      │         Visitor complexity may not be justified.
                                      │
                                      └─ YES ──► Do operations need to be 
                                                  developed/deployed independently?
                                                  │
                                                  ├─ NO ──► EVALUATE carefully.
                                                  │         Visitor may still not be worth it.
                                                  │
                                                  └─ YES ──► Does your language lack 
                                                              pattern matching / sealed types?
                                                              │
                                                              ├─ Has good pattern matching
                                                              │   (Rust, Kotlin, Scala)
                                                              │   ──► Use language features
                                                              │
                                                              └─ No pattern matching
                                                                  (Java, TypeScript)
                                                                  │
                                                                  └─► ✅ USE VISITOR PATTERN

Quick Decision Matrix
Criterion	Points FOR Visitor	Points AGAINST Visitor
Type stability	Types stable 1+ years (+3)	New types monthly (-5)
Operation count	5+ operations (+2)	1-2 operations (-3)
Operation growth	Expect 3+ new ops/year (+3)	Operations stable (-2)
Team separation	Different teams for ops (+2)	Single team (-1)
Deployment model	Independent op deployment (+2)	Monolith (-1)
Language	Java/C#/TypeScript (+1)	Rust/Kotlin/Scala (-2)

Scoring Your Situation

Add up the points from the matrix:

+8 or higher: Visitor is strongly recommended
+3 to +7: Visitor is worth considering
-2 to +2: Borderline—try simpler approaches first
-3 or lower: Avoid Visitor—use alternatives

Summary

Let's consolidate the decision criteria for the Visitor pattern:

Key Takeaways

•Use Visitor when types are stable and operations grow: It optimizes for adding operations, not types.
•Avoid Visitor when types change frequently: Every new type means updating every visitor.
•Consider alternatives first: Polymorphism, discriminated unions, pattern matching may be simpler.
•Watch for smells: Explosion of visit methods, mostly-empty visitors, frequent type additions.
•Use the decision framework: Evaluate your specific situation rather than applying patterns blindly.
•Language matters: Some languages have better built-in solutions than the Visitor pattern.

Page Complete

3 / 4