Problem: Adding Operations Without Modifying Classes - Visitor Pattern | OneNoughtOne

0/246

System Design (LLD)Visitor Pattern

Visitor Pattern: Adding Operations Without Modifying Classes

LevelIntermediate

Duration60 mins

TopicVisitor Pattern

1 / 4

Problem: Adding Operations Without Modifying Classes

The Operations Dilemma

Imagine you're working on a document processing system. You have a well-designed class hierarchy representing different document elements: paragraphs, headings, images, tables, and code blocks. The system works beautifully for rendering documents to HTML.

Then requirements arrive:

"We need to export documents to PDF format."
"Please add word count statistics."
"We need accessibility validation for all elements."
"Can we add syntax highlighting for code blocks in different output formats?"
"We need to generate a table of contents from headings."

Each new requirement means a new operation on every element type. How do you add these operations without constantly modifying your stable, well-tested element classes?

What You Will Learn

By the end of this page, you will deeply understand the problem of adding operations to closed class hierarchies—the tension between stability and extensibility that the Visitor pattern elegantly resolves. You'll see why naive approaches fail and how this problem appears across domains.

The Stable Class Hierarchy Paradox

Well-designed object-oriented systems strive for stable class hierarchies. Once a class is tested, documented, and deployed, modifying it introduces risk:

Regression Risk: Changes might break existing functionality
Testing Burden: All dependent code must be retested
Deployment Coordination: Changes require synchronized deployments
Open/Closed Principle Violation: Classes should be open for extension but closed for modification

Yet real-world requirements constantly demand new operations on existing object structures. This creates a fundamental paradox:

The Extensibility Paradox

The more stable and well-tested a class hierarchy becomes, the more painful it is to add new operations—yet stable hierarchies are precisely where new requirements accumulate.

Mature systems with stable domain models face this paradox most acutely. The document processor example isn't hypothetical—it represents any system with stable entities and evolving behavior requirements.

The Two Dimensions of Extension

Object-oriented design offers two orthogonal dimensions for extension:

Dimension	Mechanism	Easy When...	Hard When...
Add New Types	Inheritance/Polymorphism	Behavior is fixed	Operations must be added
Add New Operations	Method addition	Class hierarchy is open	Classes are closed/stable

Most OOP systems excel at adding new types. Want a new document element? Create a VideoElement class implementing the existing interface. The system handles it naturally through polymorphism.

But adding new operations—that's where traditional OOP struggles. Each new operation requires modifying every class in the hierarchy.

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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
// Initial design: Rendering to HTML
interface DocumentElement {
    renderHtml(): string;
}
 
class Paragraph implements DocumentElement {
    constructor(private text: string) {}
    
    renderHtml(): string {
        return `<p>${this.text}</p>`;
    }
}
 
class Heading implements DocumentElement {
    constructor(private text: string, private level: number) {}
    
    renderHtml(): string {
        return `<h${this.level}>${this.text}</h${this.level}>`;
    }
}
 
class Image implements DocumentElement {
    constructor(private src: string, private alt: string) {}
    
    renderHtml(): string {
        return `<img src="${this.src}" alt="${this.alt}" />`;
    }
}
 
class CodeBlock implements DocumentElement {
    constructor(private code: string, private language: string) {}
    
    renderHtml(): string {
        return `<pre><code class="language-${this.language}">${this.code}</code></pre>`;
    }
}
 
// ❌ PROBLEM: Now we need PDF export. We must modify EVERY class:
 
interface DocumentElement {
    renderHtml(): string;
    renderPdf(): PdfNode;        // Added to interface
}
 
class Paragraph implements DocumentElement {
    renderHtml(): string { /* ... */ }
    renderPdf(): PdfNode {       // Added to Paragraph
        return new PdfTextBlock(this.text, { font: 'serif', size: 12 });
    }
}
 
class Heading implements DocumentElement {
    renderHtml(): string { /* ... */ }
    renderPdf(): PdfNode {       // Added to Heading
        const sizes = { 1: 24, 2: 20, 3: 16, 4: 14, 5: 12, 6: 10 };
        return new PdfTextBlock(this.text, { 
            font: 'sans-serif', 
            size: sizes[this.level], 
            bold: true 
        });
    }
}
 
// ... and so on for Image, CodeBlock, Table, etc.
 
// ❌ WORSE: Now we need word count, accessibility check, TOC generation...
// Each operation requires modifying EVERY class in the hierarchy!

Why Naive Solutions Fail

Before exploring the Visitor pattern, let's examine why common alternatives fall short. Understanding their limitations illuminates what problem we're actually solving.

Naive Approach #1: Add Methods to Every Class

•Approach: Add new methods (renderPdf(), countWords(), etc.) directly to each element class.
•Why It Fails: Violates Open/Closed Principle. Every new operation requires changing every class. If you have 20 element types and 10 operations, that's 200 method implementations scattered across 20 files.
•Consequences: Testing burden multiplies. Merge conflicts increase. Teams can't work independently on different operations.

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
// Every class becomes bloated with unrelated operations:
class Paragraph implements DocumentElement {
    constructor(private text: string) {}
    
    // Core functionality
    renderHtml(): string { /* ... */ }
    
    // PDF requirement
    renderPdf(): PdfNode { /* ... */ }
    
    // Analytics requirement
    countWords(): number { /* ... */ }
    
    // Accessibility requirement  
    validateAccessibility(): AccessibilityReport { /* ... */ }
    
    // TOC requirement
    extractHeadings(): Heading[] { return []; } // Not a heading, so empty
    
    // Search requirement
    extractSearchableText(): string { /* ... */ }
    
    // Comparison requirement
    structuralHash(): string { /* ... */ }
    
    // ... 10 more operations accumulate over time
}
 
// ❌ Problems:
// 1. Class has too many responsibilities (SRP violation)
// 2. Every new operation opens every class for modification
// 3. Operations team can't add features without element team review
// 4. 20 classes × 15 operations = 300 methods to maintain

Naive Approach #2: Type Checking with instanceof

•Approach: Put operation logic in external functions that check element types with instanceof or type tags.
•Why It Fails: Violates Open/Closed Principle in a different dimension. Adding new element types requires modifying every operation function. Type checking is error-prone and loses static type safety.
•Consequences: Forgetting to handle a type causes runtime errors. No compiler help when types are added. Switch statements grow unwieldy.

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
// External operations check types:
function renderPdf(element: DocumentElement): PdfNode {
    if (element instanceof Paragraph) {
        return new PdfTextBlock(element.getText(), { font: 'serif', size: 12 });
    } else if (element instanceof Heading) {
        const sizes = { 1: 24, 2: 20, 3: 16, 4: 14, 5: 12, 6: 10 };
        return new PdfTextBlock(element.getText(), { 
            font: 'sans-serif', 
            size: sizes[element.getLevel()],
            bold: true 
        });
    } else if (element instanceof Image) {
        return new PdfImage(element.getSrc());
    } else if (element instanceof CodeBlock) {
        return new PdfCodeBlock(element.getCode(), element.getLanguage());
    } else if (element instanceof Table) {
        return new PdfTable(element.getRows());
    }
    // ... 15 more type checks
    
    throw new Error(`Unknown element type: ${element.constructor.name}`);
}
 
function countWords(element: DocumentElement): number {
    if (element instanceof Paragraph) {
        return element.getText().split(/\s+/).length;
    } else if (element instanceof Heading) {
        return element.getText().split(/\s+/).length;
    } else if (element instanceof Image) {
        return element.getAlt().split(/\s+/).length;
    }
    // ... same exhaustive type checking repeated
}
 
// ❌ Problems:
// 1. Runtime errors if new types aren't handled
// 2. No compile-time exhaustiveness checking
// 3. Each operation duplicates the type-checking logic
// 4. Logic for one operation scattered if types are added
// 5. Breaks encapsulation - operations need access to internal state

Naive Approach #3: Parallel Hierarchies

•Approach: Create parallel class hierarchies for each operation (ParagraphPdfRenderer, HeadingPdfRenderer, etc.).
•Why It Fails: Explosion of classes. For N element types and M operations, you need N × M renderer classes plus complex lookup/factory logic to connect them.
•Consequences: Massive boilerplate. Adding an element type requires adding M renderer classes. Lookup logic becomes a maintenance nightmare.

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
54
55
56
57
// Parallel renderer hierarchies for each operation:
 
// PDF Renderers
interface PdfRenderer<T extends DocumentElement> {
    render(element: T): PdfNode;
}
 
class ParagraphPdfRenderer implements PdfRenderer<Paragraph> {
    render(element: Paragraph): PdfNode { /* ... */ }
}
 
class HeadingPdfRenderer implements PdfRenderer<Heading> {
    render(element: Heading): PdfNode { /* ... */ }
}
 
class ImagePdfRenderer implements PdfRenderer<Image> {
    render(element: Image): PdfNode { /* ... */ }
}
 
// Word Counters
interface WordCounter<T extends DocumentElement> {
    count(element: T): number;
}
 
class ParagraphWordCounter implements WordCounter<Paragraph> {
    count(element: Paragraph): number { /* ... */ }
}
 
class HeadingWordCounter implements WordCounter<Heading> {
    count(element: Heading): number { /* ... */ }
}
 
// Accessibility Validators, TOC Extractors, Search Indexers...
 
// ❌ For 20 element types × 10 operations = 200 classes!
 
// Plus you need registry/factory to connect them:
class RendererRegistry {
    private pdfRenderers: Map<Constructor, PdfRenderer<any>> = new Map();
    private wordCounters: Map<Constructor, WordCounter<any>> = new Map();
    // ... maps for each operation type
    
    constructor() {
        this.pdfRenderers.set(Paragraph, new ParagraphPdfRenderer());
        this.pdfRenderers.set(Heading, new HeadingPdfRenderer());
        // ... 18 more registrations for PDF
        // ... then repeat for each operation type
    }
    
    getPdfRenderer(element: DocumentElement): PdfRenderer<DocumentElement> {
        const renderer = this.pdfRenderers.get(element.constructor);
        if (!renderer) throw new Error('No renderer registered');
        return renderer;
    }
}
 
// ❌ This is becoming a maintenance nightmare

The Core Tension

All naive approaches suffer from the same fundamental tension: adding a new operation requires changes proportional to the number of types, or adding a new type requires changes proportional to the number of operations.

We can't escape this mathematical reality—but we CAN choose which dimension we optimize for. The Visitor pattern chooses to optimize for adding operations when types are stable.

When This Problem Is Acute

The operation-extension problem isn't equally painful in all scenarios. Understanding when it's most acute helps you recognize Visitor pattern opportunities.

Scenarios Where Operation Extension Pain Is Greatest

•Compilers and Interpreters: AST (Abstract Syntax Trees) have fixed node types (expressions, statements, declarations) but constantly need new operations (type checking, optimization, code generation, pretty printing, linting).
•Document Processors: Document elements are stable (paragraph, heading, list, table, image), but export formats and analyses multiply (HTML, PDF, EPUB, word count, accessibility validation).
•GUI Toolkits: Widget hierarchies (button, textfield, container, menu) are stable, but operations accumulate (render, layout, serialize, accessibility, theming).
•Financial Systems: Transaction types stabilize (deposit, withdrawal, transfer, fee), but reporting and analysis operations grow indefinitely.
•Game Engines: Entity types are defined (character, projectile, terrain, item), but systems operating on them multiply (physics, rendering, AI, serialization).

Characteristics of Visitor-Appropriate Domains
Characteristic	Description	Example
Stable Type Hierarchy	Element types change rarely after initial design	AST nodes in a mature language
Frequent Operation Addition	New operations are added more often than new types	IDE features for code analysis
Complex Object Structures	Elements form trees or graphs needing traversal	Document DOMs, scene graphs
Operations Cross-Cut Types	Same operation applies to all/most types	Serialization, validation
Separation of Concerns	Operation logic should be separate from element logic	Rendering separate from data model

The Compiler Archetype

Compilers are the canonical example. Language syntax (AST node types) changes slowly—maybe a few new constructs per major version. But operations on the AST are added continually: type inference, dead code elimination, constant folding, register allocation, various code generation targets, IDE features like go-to-definition, find-references, refactoring.

The Visitor pattern was essentially invented for this domain, though it applies broadly.

The Real-World AST Example

Let's examine the problem through the lens of a simple expression AST. This example illustrates how quickly operations accumulate on a stable type hierarchy.

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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
// A simple expression language AST
// These types are STABLE - they define what expressions can exist
 
abstract class Expression {
    abstract evaluate(): number;  // The only built-in operation
}
 
class NumberLiteral extends Expression {
    constructor(public readonly value: number) { super(); }
    
    evaluate(): number {
        return this.value;
    }
}
 
class BinaryOperation extends Expression {
    constructor(
        public readonly left: Expression,
        public readonly operator: '+' | '-' | '*' | '/',
        public readonly right: Expression
    ) { super(); }
    
    evaluate(): number {
        const l = this.left.evaluate();
        const r = this.right.evaluate();
        switch (this.operator) {
            case '+': return l + r;
            case '-': return l - r;
            case '*': return l * r;
            case '/': return l / r;
        }
    }
}
 
class UnaryOperation extends Expression {
    constructor(
        public readonly operator: '-' | '+',
        public readonly operand: Expression
    ) { super(); }
    
    evaluate(): number {
        const val = this.operand.evaluate();
        return this.operator === '-' ? -val : val;
    }
}
 
class VariableReference extends Expression {
    constructor(
        public readonly name: string,
        private readonly environment: Map<string, number>
    ) { super(); }
    
    evaluate(): number {
        const value = this.environment.get(this.name);
        if (value === undefined) {
            throw new Error(`Undefined variable: ${this.name}`);
        }
        return value;
    }
}
 
class FunctionCall extends Expression {
    constructor(
        public readonly functionName: string,
        public readonly args: Expression[]
    ) { super(); }
    
    evaluate(): number {
        // Built-in functions
        const argValues = this.args.map(a => a.evaluate());
        switch (this.functionName) {
            case 'sqrt': return Math.sqrt(argValues[0]);
            case 'pow': return Math.pow(argValues[0], argValues[1]);
            case 'abs': return Math.abs(argValues[0]);
            default: throw new Error(`Unknown function: ${this.functionName}`);
        }
    }
}

This AST is clean and focused. Each node knows how to evaluate itself. But then requirements arrive:

Week 1: "We need to pretty-print expressions for debugging." Week 2: "Add support for serializing expressions to JSON." Week 3: "We need type checking for a statically-typed variant." Week 4: "Add optimization passes—constant folding, redundant operation elimination." Week 5: "Generate LLVM IR for JIT compilation." Week 6: "Collect variable references for scope analysis." Week 7: "Compute expression complexity for query planning."

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
54
55
56
57
58
59
60
61
// Without Visitor pattern, Expression classes bloat:
 
abstract class Expression {
    // Core
    abstract evaluate(): number;
    
    // Pretty printing
    abstract prettyPrint(): string;
    abstract prettyPrintWithParens(): string;
    
    // Serialization
    abstract toJson(): object;
    abstract toXml(): string;
    
    // Type checking
    abstract inferType(): ExpressionType;
    abstract checkType(expected: ExpressionType): TypeError[];
    
    // Optimization
    abstract foldConstants(): Expression;
    abstract simplify(): Expression;
    abstract isConstant(): boolean;
    
    // Code generation
    abstract generateLlvmIr(builder: IrBuilder): Value;
    abstract generateJvmBytecode(writer: BytecodeWriter): void;
    
    // Analysis
    abstract collectVariables(): Set<string>;
    abstract computeDepth(): number;
    abstract computeComplexity(): number;
    
    // And more operations accumulate...
}
 
// Every concrete class must implement ALL of these:
class NumberLiteral extends Expression {
    evaluate(): number { /* ... */ }
    prettyPrint(): string { /* ... */ }
    prettyPrintWithParens(): string { /* ... */ }
    toJson(): object { /* ... */ }
    toXml(): string { /* ... */ }
    inferType(): ExpressionType { /* ... */ }
    checkType(expected: ExpressionType): TypeError[] { /* ... */ }
    foldConstants(): Expression { /* ... */ }
    simplify(): Expression { /* ... */ }
    isConstant(): boolean { /* ... */ }
    generateLlvmIr(builder: IrBuilder): Value { /* ... */ }
    generateJvmBytecode(writer: BytecodeWriter): void { /* ... */ }
    collectVariables(): Set<string> { /* ... */ }
    computeDepth(): number { /* ... */ }
    computeComplexity(): number { /* ... */ }
    // ... 15+ methods in a "simple" number literal class
}
 
// ❌ Problems:
// 1. Expression classes have become god classes
// 2. Adding new operations requires changing 5+ files
// 3. LLVM code generation logic mixed with JSON serialization
// 4. Can't version operations independently
// 5. Testing nightmare - each class tests 15+ behaviors

The Real Cost

This isn't theoretical. Production compilers, interpreters, and document processors that don't use the Visitor pattern (or an equivalent) become unmaintainable. Adding a single operation to TypeScript's AST would require changes to hundreds of node type classes. The Visitor pattern is why they remain maintainable.

The Expression Problem Formally

What we've been exploring has a formal name in programming language theory: The Expression Problem. Coined by Philip Wadler in 1998, it captures a fundamental tension in language design.

The Expression Problem Defined

The Expression Problem: Define a data type by cases, where one can add new cases to the data type and new functions over the data type, without recompiling existing code, while retaining static type safety.

— Philip Wadler, 1998

The problem reveals a fundamental asymmetry between object-oriented and functional approaches:

Object-Oriented Style (Classes + Methods):

✅ Easy to add new types (data cases): Just add a new class implementing the interface
❌ Hard to add new operations: Must modify all existing classes

Functional Style (Data Types + Pattern Matching):

✅ Easy to add new operations: Just add a new function with pattern matching
❌ Hard to add new types: Must modify all existing functions' pattern matches

Neither approach solves both dimensions simultaneously without trade-offs.

The Expression Problem: OO vs Functional Trade-offs
Paradigm	Add New Type	Add New Operation	Type Safety
Object-Oriented (Methods in Classes)	✅ Easy - new subclass	❌ Hard - modify all classes	✅ Static
Functional (Pattern Matching)	❌ Hard - modify all functions	✅ Easy - new function	✅ Static
Visitor Pattern	❌ Hard - modify all visitors	✅ Easy - new visitor	✅ Static
Type Classes (Haskell)	✅ Moderate - new instance	✅ Moderate - new class	✅ Static

The Visitor Pattern's Trade-off

The Visitor pattern explicitly chooses one side of the trade-off:

Optimized for adding operations: New visitors can be added without touching element classes
Sacrifices easy type addition: Adding a new element type requires updating all existing visitors

This is the right choice when:

Element types are stable (change rarely)
Operations are volatile (change frequently)
Operations need to be versioned/deployed independently

It's the wrong choice when element types change frequently—in that case, traditional polymorphism is better.

The Expression Problem Matrix:
═══════════════════════════════════════════════════════════════
 
                        OPERATIONS
                   ┌─────────────────┐
                   │ Op1  Op2  Op3  ...
           ┌───────┼─────────────────┤
           │TypeA  │  ✓    ✓    ✓   │
   TYPES   │TypeB  │  ✓    ✓    ✓   │  ← Each cell is an
           │TypeC  │  ✓    ✓    ✓   │    implementation
           │...    │               │
           └───────┴─────────────────┘
 
OO Approach: Easy to add rows (types), hard to add columns (operations)
FP Approach: Easy to add columns (operations), hard to add rows (types)
Visitor:     Explicitly chooses to add columns easily
 
═══════════════════════════════════════════════════════════════
 
Adding a NEW TYPE (with Visitor):
                        OPERATIONS
                   ┌─────────────────────┐
                   │ Op1  Op2  Op3  ...
           ┌───────┼─────────────────────┤
           │TypeA  │  ✓    ✓    ✓       │
   TYPES   │TypeB  │  ✓    ✓    ✓       │
           │TypeC  │  ✓    ✓    ✓       │
           │TypeD  │  ?    ?    ?       │ ← Must implement in EVERY visitor!
           └───────┴─────────────────────┘
 
Adding a NEW OPERATION (with Visitor):
                        OPERATIONS
                   ┌────────────────────────┐
                   │ Op1  Op2  Op3  Op4 ...
           ┌───────┼────────────────────────┤
           │TypeA  │  ✓    ✓    ✓    ?     │
   TYPES   │TypeB  │  ✓    ✓    ✓    ?     │ All in ONE new file!
           │TypeC  │  ✓    ✓    ✓    ?     │
           └───────┴────────────────────────┘
                                       ↑
                             One new visitor class
                             handles all types

Why Object Hierarchies Resist Operations

To truly understand the Visitor pattern, we need to understand why object-oriented polymorphism—despite its power—can't solve the operation-extension problem.

Single Dispatch: The Root Limitation

Most object-oriented languages use single dispatch: method selection is based solely on the runtime type of the receiver object (the object before the dot).

element.render();  // Method selected based on element's runtime type

When you call render(), the language looks up which render implementation to execute based on whether element is a Paragraph, Heading, Image, etc. This is polymorphism—elegant and powerful.

But what if the behavior depends on two types? What if rendering depends on both:

The type of element being rendered
The type of renderer (HTML vs PDF vs Markdown)?

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
// We want behavior to depend on TWO types:
// 1. What kind of element is this?
// 2. What kind of output do we want?
 
abstract class Element {
    // This method only dispatches on Element type
    abstract render(renderer: Renderer): string;
}
 
abstract class Renderer {
    // This method only dispatches on Renderer type (if called on Renderer)
    abstract renderParagraph(p: Paragraph): string;
    abstract renderHeading(h: Heading): string;
    // ...
}
 
// With single dispatch, we can only pick ONE to be polymorphic:
 
// Option A: Dispatch on Element, but Renderer type is static
class Paragraph extends Element {
    render(renderer: Renderer): string {
        // We know this is a Paragraph, but what KIND of Renderer?
        // We'd have to use instanceof checks:
        if (renderer instanceof HtmlRenderer) {
            return `<p>${this.text}</p>`;
        } else if (renderer instanceof PdfRenderer) {
            return renderer.createPdfParagraph(this.text);
        }
        // ❌ Back to type checking!
    }
}
 
// Option B: Dispatch on Renderer, but Element type is static
class HtmlRenderer extends Renderer {
    renderAny(element: Element): string {
        // We know this is HtmlRenderer, but what KIND of Element?
        if (element instanceof Paragraph) {
            return `<p>${element.text}</p>`;
        } else if (element instanceof Heading) {
            return `<h${element.level}>${element.text}</h${element.level}>`;
        }
        // ❌ Also back to type checking!
    }
}
 
// Neither approach achieves polymorphism on BOTH dimensions!

What We Really Need: Double Dispatch

The Visitor pattern's genius is simulating double dispatch (dispatch based on two types) using two single dispatches. The first dispatch is on the element type (via accept), the second is on the visitor type (via the specific visit method called). Together, they achieve behavior that depends on both types—without any instanceof checks.

Problem Summary

Let's consolidate everything we've learned about the operation-extension problem:

Key Problem Characteristics

•Stable Object Hierarchy: You have a class hierarchy that's well-designed, tested, and shouldn't change frequently.
•Frequent Operation Addition: New operations need to be added to all classes in the hierarchy regularly.
•Open/Closed Tension: Adding operations by modifying classes violates the Open/Closed Principle and introduces risk.
•Single Dispatch Limitation: OOP's single dispatch can't naturally model operations that depend on both element type and operation type.
•Cross-Cutting Operations: Operations apply across the type hierarchy, not to isolated classes.

What We Want to Avoid

•Modifying stable element classes
•Type-checking with instanceof
•Explosion of parallel hierarchies
•God classes with dozens of methods
•Tightly coupled operation code

What We Want to Achieve

•Add operations without touching elements
•Type-safe dispatch on multiple types
•Operations self-contained in single files
•Focused classes with clear responsibilities
•Independently deployable operations

Page Complete

You now understand the problem that the Visitor pattern solves: how to add new operations to a stable object structure without modifying its classes. You've seen why naive approaches fail and where this problem is most acute. Next, we'll explore the Visitor pattern's elegant solution using double dispatch—turning the single-dispatch limitation into an advantage.