6a:T758,// Initial design: Rendering to HTML interface DocumentElement { renderHtml(): string; } class Paragraph implements DocumentElement { constructor(private text: string) {} renderHtml(): string { return `

${this.text}

`; } } class Heading implements DocumentElement { constructor(private text: string, private level: number) {} renderHtml(): string { return `${this.text}`; } } class Image implements DocumentElement { constructor(private src: string, private alt: string) {} renderHtml(): string { return ` ${this.alt}

`; } } class CodeBlock implements DocumentElement { constructor(private code: string, private language: string) {} renderHtml(): string { return `

${this.code}

`; } } // ❌ 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!6b:T412,// 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 maintain6c:T650,// 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 state6d:T6f7,// Parallel renderer hierarchies for each operation: // PDF Renderers interface PdfRenderer { render(element: T): PdfNode; } class ParagraphPdfRenderer implements PdfRenderer { render(element: Paragraph): PdfNode { /* ... */ } } class HeadingPdfRenderer implements PdfRenderer { render(element: Heading): PdfNode { /* ... */ } } class ImagePdfRenderer implements PdfRenderer { render(element: Image): PdfNode { /* ... */ } } // Word Counters interface WordCounter { count(element: T): number; } class ParagraphWordCounter implements WordCounter { count(element: Paragraph): number { /* ... */ } } class HeadingWordCounter implements WordCounter { 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> = new Map(); private wordCounters: Map> = 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 { const renderer = this.pdfRenderers.get(element.constructor); if (!renderer) throw new Error('No renderer registered'); return renderer; } } // ❌ This is becoming a maintenance nightmare6e:T897,// 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 ) { 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}`); } } }6f:T820,// 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; 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 { /* ... */ } 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+ behaviors70:Ta3d,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 types71:T633,// 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 `

${this.text}

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

${element.text}

`; } else if (element instanceof Heading) { return `${element.text}`; } // ❌ Also back to type checking! } } // Neither approach achieves polymorphism on BOTH dimensions!62:{"json":{"id":"seed_f46b9474a059647934631c2dbb09cd47","slug":"visitor-pattern","category":"System Design (LLD)","topic":"Visitor Pattern","title":"Visitor Pattern: Adding Operations Without Modifying Classes","description":"Master the Visitor pattern—a powerful behavioral design pattern that enables adding new operations to object structures without modifying their classes. Learn about double dispatch, element-visitor interaction, and when this pattern shines versus when simpler approaches suffice.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_10ec32ccbccf6ca87e72d2fd14ac6245","title":"Problem: Adding Operations Without Modifying Classes","order":0,"content":[{"id":"opening-hook","title":"The Operations Dilemma","content":[{"data":{"content":"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.\n\nThen requirements arrive:\n\n1. *\"We need to export documents to PDF format.\"*\n2. *\"Please add word count statistics.\"*\n3. *\"We need accessibility validation for all elements.\"*\n4. *\"Can we add syntax highlighting for code blocks in different output formats?\"*\n5. *\"We need to generate a table of contents from headings.\"*\n\nEach 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?"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"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.","variant":"info"},"type":"callout"}]},{"id":"stable-hierarchy-paradox","title":"The Stable Class Hierarchy Paradox","content":[{"data":{"content":"Well-designed object-oriented systems strive for **stable class hierarchies**. Once a class is tested, documented, and deployed, modifying it introduces risk:\n\n- **Regression Risk**: Changes might break existing functionality\n- **Testing Burden**: All dependent code must be retested\n- **Deployment Coordination**: Changes require synchronized deployments\n- **Open/Closed Principle Violation**: Classes should be open for extension but closed for modification\n\nYet real-world requirements constantly demand new operations on existing object structures. This creates a fundamental paradox:"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Extensibility Paradox","content":"**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.**\n\nMature 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.","variant":"warning"},"type":"callout"},{"data":{"content":"**The Two Dimensions of Extension**\n\nObject-oriented design offers two orthogonal dimensions for extension:"},"type":"text"},{"data":{"rows":[["**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"]],"headers":["Dimension","Mechanism","Easy When...","Hard When..."]},"type":"table"},{"data":{"content":"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.\n\nBut adding new operations—that's where traditional OOP struggles. Each new operation requires modifying every class in the hierarchy."},"type":"text"},{"data":{"code":"$6a","title":"The Problem in Code: Adding Operations Requires Modifying Every Class","language":"typescript"},"type":"code"}],"titleType":"number","titleNumber":1},{"id":"naive-solutions-fail","title":"Why Naive Solutions Fail","content":[{"data":{"content":"Before exploring the Visitor pattern, let's examine why common alternatives fall short. Understanding their limitations illuminates what problem we're actually solving."},"type":"text"},{"data":{"items":["**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."],"title":{"icon":"XCircle","text":"Naive Approach #1: Add Methods to Every Class","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"code":"$6b","title":"Approach #1: Direct Method Addition (Problematic)","language":"typescript"},"type":"code"},{"data":{"items":["**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."],"title":{"icon":"XCircle","text":"Naive Approach #2: Type Checking with instanceof","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"code":"$6c","title":"Approach #2: Type Checking (Also Problematic)","language":"typescript"},"type":"code"},{"data":{"items":["**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."],"title":{"icon":"XCircle","text":"Naive Approach #3: Parallel Hierarchies","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"code":"$6d","title":"Approach #3: Parallel Hierarchies (Unmanageable)","language":"typescript"},"type":"code"},{"data":{"icon":"Info","title":"The Core Tension","content":"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.**\n\nWe 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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"when-problem-acute","title":"When This Problem Is Acute","content":[{"data":{"content":"The operation-extension problem isn't equally painful in all scenarios. Understanding when it's most acute helps you recognize Visitor pattern opportunities."},"type":"text"},{"data":{"items":["**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)."],"title":{"icon":"AlertCircle","text":"Scenarios Where Operation Extension Pain Is Greatest","type":"icon","color":"accent","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"rows":[["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"]],"caption":"Characteristics of Visitor-Appropriate Domains","headers":["Characteristic","Description","Example"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"The Compiler Archetype","content":"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.\n\nThe Visitor pattern was essentially invented for this domain, though it applies broadly.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"ast-example","title":"The Real-World AST Example","content":[{"data":{"content":"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."},"type":"text"},{"data":{"code":"$6e","title":"Expression AST: A Stable Type Hierarchy","language":"typescript"},"type":"code"},{"data":{"content":"This AST is clean and focused. Each node knows how to evaluate itself. But then requirements arrive:\n\n**Week 1**: *\"We need to pretty-print expressions for debugging.\"*\n**Week 2**: *\"Add support for serializing expressions to JSON.\"*\n**Week 3**: *\"We need type checking for a statically-typed variant.\"*\n**Week 4**: *\"Add optimization passes—constant folding, redundant operation elimination.\"*\n**Week 5**: *\"Generate LLVM IR for JIT compilation.\"*\n**Week 6**: *\"Collect variable references for scope analysis.\"*\n**Week 7**: *\"Compute expression complexity for query planning.\"*"},"type":"text"},{"data":{"code":"$6f","title":"The Problem: Expressions Bloated with Operations","language":"typescript"},"type":"code"},{"data":{"icon":"AlertCircle","title":"The Real Cost","content":"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.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"expression-problem","title":"The Expression Problem Formally","content":[{"data":{"content":"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."},"type":"text"},{"data":{"icon":"Info","title":"The Expression Problem Defined","content":"**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.\n\n— Philip Wadler, 1998","variant":"note"},"type":"callout"},{"data":{"content":"The problem reveals a fundamental asymmetry between object-oriented and functional approaches:\n\n**Object-Oriented Style (Classes + Methods)**:\n- ✅ Easy to add new types (data cases): Just add a new class implementing the interface\n- ❌ Hard to add new operations: Must modify all existing classes\n\n**Functional Style (Data Types + Pattern Matching)**:\n- ✅ Easy to add new operations: Just add a new function with pattern matching\n- ❌ Hard to add new types: Must modify all existing functions' pattern matches\n\n**Neither approach solves both dimensions simultaneously without trade-offs.**"},"type":"text"},{"data":{"rows":[["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"]],"caption":"The Expression Problem: OO vs Functional Trade-offs","headers":["Paradigm","Add New Type","Add New Operation","Type Safety"]},"type":"table"},{"data":{"content":"**The Visitor Pattern's Trade-off**\n\nThe Visitor pattern explicitly chooses one side of the trade-off:\n\n- **Optimized for adding operations**: New visitors can be added without touching element classes\n- **Sacrifices easy type addition**: Adding a new element type requires updating all existing visitors\n\nThis is the right choice when:\n1. Element types are stable (change rarely)\n2. Operations are volatile (change frequently)\n3. Operations need to be versioned/deployed independently\n\nIt's the wrong choice when element types change frequently—in that case, traditional polymorphism is better."},"type":"text"},{"data":{"code":"$70","title":"Visualizing the Trade-off","language":"text"},"type":"code"}],"titleType":"number","titleNumber":5},{"id":"why-hierarchies-resist","title":"Why Object Hierarchies Resist Operations","content":[{"data":{"content":"To truly understand the Visitor pattern, we need to understand why object-oriented polymorphism—despite its power—can't solve the operation-extension problem."},"type":"text"},{"data":{"content":"**Single Dispatch: The Root Limitation**\n\nMost object-oriented languages use **single dispatch**: method selection is based solely on the runtime type of the receiver object (the object before the dot).\n\n```typescript\nelement.render(); // Method selected based on element's runtime type\n```\n\nWhen 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.\n\nBut what if the behavior depends on **two** types? What if rendering depends on both:\n1. The type of element being rendered\n2. The type of renderer (HTML vs PDF vs Markdown)?"},"type":"text"},{"data":{"code":"$71","title":"The Single Dispatch Limitation","language":"typescript"},"type":"code"},{"data":{"icon":"Lightbulb","title":"What We Really Need: Double Dispatch","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"problem-summary","title":"Problem Summary","content":[{"data":{"content":"Let's consolidate everything we've learned about the operation-extension problem:"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"CheckCircle","text":"Key Problem Characteristics","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"left":[{"data":{"items":["Modifying stable element classes","Type-checking with instanceof","Explosion of parallel hierarchies","God classes with dozens of methods","Tightly coupled operation code"],"title":{"icon":"XCircle","text":"What We Want to Avoid","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"right":[{"data":{"items":["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"],"title":{"icon":"CheckCircle","text":"What We Want to Achieve","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"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.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_563fc2705fce085ff7d103c61b359d92","title":"Solution: Visitor with Double Dispatch","order":1,"content":null,"isLocked":true},{"id":"seed_0bc6e7b55022f6ab773502c92fe15451","title":"When to Use Visitor","order":2,"content":null,"isLocked":true},{"id":"seed_ea4116f4509ea6c0b0d5212a67db8595","title":"Use Cases and Examples","order":3,"content":null,"isLocked":true}]}}