Visitor

Real-world analogy

A government tax auditor visiting different financial entities illustrates the Visitor pattern. A software contractor, a corporate enterprise, and a charitable foundation do not maintain complex tax calculation algorithms inside their own company classes. Instead, they implement an accept(Auditor a) method. When the tax auditor visits, each entity calls auditor.visitContractor(this) or auditor.visitCharity(this). The auditor executes the specific tax assessment formulas externally, leaving the corporate entities focused purely on their business operations.

The problem

You are building a rich text document processing engine. A document consists of an Abstract Syntax Tree (AST) composed of different node elements: Paragraph, Heading, CodeSnippet, and ImageElement.

Initially, you need to render the document to HTML. Soon, product managers request:

• Export to Markdown.
• Export to Plain Text.
• Spell-checking and grammar linting.
• Word count and reading time statistics calculation.

If you add each new operation directly as a method inside every AST node class, the node classes become bloated with unrelated formatting and parsing concerns:

1 // Naive implementation: Polluting AST elements with every operational concern
2 class Paragraph {
3   constructor(text) { this.text = text; }
4 
5   // Polluted with export, linting, and metrics code
6   toHtml() { return `<p>${this.text}</p>`; }
7   toMarkdown() { return `${this.text}\n\n`; }
8   spellCheck(dictionary) { /* 50 lines of spell-checking logic */ }
9   calculateWordCount() { return this.text.split(" ").length; }
10 }
11 
12 class CodeSnippet {
13   constructor(code, lang) { this.code = code; this.lang = lang; }
14 
15   toHtml() { return `<pre><code>${this.code}</code></pre>`; }
16   toMarkdown() { return `\`\`\`${this.lang}\n${this.code}\n\`\`\`\n\n`; }
17   spellCheck() { /* Skip code blocks */ }
18   calculateWordCount() { return 0; }
19 }

1 public class Example {
2     static class Paragraph {
3         String text;
4         public String toHtml() { return "<p>" + text + "</p>"; }
5         public String toMarkdown() { return text + "\n\n"; }
6         public void spellCheck() { /* Spell check logic */ }
7         public int countWords() { return text.split(" ").length

Adding a sixth operation (e.g. toPdf() or securitySanitize()) forces you to modify every single element class in the AST, violating the Single Responsibility Principle and the Open/Closed Principle.

The solution

The Visitor pattern extracts operations out of the element classes into separate Visitor classes. The element classes define a single accept(Visitor v) method. When called, the element passes itself to the visitor's corresponding visit method (v.visitParagraph(this)).

• Visitor (DocumentVisitor): Interface declaring a visit method for every concrete element type (visitHeading, visitParagraph, visitCodeSnippet).
• Concrete Visitors (MarkdownExportVisitor, WordCountVisitor): Implements the specific operation across all element types.
• Element (DocumentElement): Declares the accept(DocumentVisitor v) method.
• Concrete Elements (Paragraph, Heading, CodeSnippet): Implements accept() via Double Dispatch (v.visit(this)).

Step-by-step implementation

Step 1: Define the visitor interface

The visitor declares a dedicated visit method for every concrete element in the structure.

1 class DocumentVisitor {
2   visitHeading(heading) {
3     throw new Error("visitHeading() must be implemented");
4   }
5   visitParagraph(paragraph) {
6     throw new Error("visitParagraph() must be implemented");
7   }
8 }

1 public class Example {
2     interface

Step 2: Define elements and double dispatch accept()

Elements implement accept(Visitor v) and pass this to the visitor.

Step 3: Implement concrete visitors

Visitors implement the operations across all elements in one encapsulated class.

The complete example

Here is the complete, runnable implementation demonstrating Markdown export and Word Count visitors operating on an AST document structure.

1 --- Rendered Markdown Output ---
2 # Design Patterns Overview
3 
4 The Visitor pattern enables adding operations without mutating existing node classes.
5 
6 ```js
7 element.accept(visitor);
8 ```
9 
10 --- Calculated Word Count ---
11 Total prose words: 14

Variations

Double dispatch explained

Why does the Visitor pattern require the seemingly convoluted element.accept(visitor) instead of calling visitor.visit(element) directly?

• In single-dispatch languages (Java, C++, C#), method dispatch depends only on the runtime type of the receiver (obj.method()), but the compile-time static type of method arguments.
• If you have DocElement el = new Heading(...), calling visitor.visit(el) causes a compiler error in Java because the compiler only knows el is a DocElement, not which specific overloaded visit(Heading) method to call.
• Double Dispatch solves this:
  1. First dispatch: el.accept(visitor) invokes the runtime method on Heading.
  2. Second dispatch: inside Heading.accept(), visitor.visitHeading(this) knows with 100% compile-time certainty that this is a Heading.

Adding operations vs adding types

Visitor creates an asymmetric architectural trade-off:

• Adding Operations is Easy: To add a PdfExportVisitor, you simply create one new class. No existing AST node classes are touched.
• Adding Types is Hard: If you add a new TableElement class to the AST, you must update the Visitor interface and add visitTable(TableElement) to every single existing visitor in the codebase.

Modern alternatives (Java 21 sealed types & pattern matching)

In modern Java 21+, sealed interfaces and pattern-matching switch statements often replace the Visitor pattern:

1 // Java 21+ alternative without Double Dispatch:
2 sealed interface DocElement permits Heading, Paragraph, CodeBlock {}
3 
4 public String renderMarkdown(DocElement el) {
5     return switch (el) {
6         case Heading h -> "#".repeat(h.level()) + " " + h.text();
7         case Paragraph p -> p.text();

The compiler verifies pattern exhaustiveness, achieving the benefits of Visitor with none of the double dispatch boilerplate.

Where you've already used it

• Babel & ESLint AST Visitors: Plugins define visitor hooks (Identifier(node), FunctionDeclaration(node)) to lint and transform JavaScript ASTs.
• Java Compiler API (javax.lang.model.element.ElementVisitor): Java compiler annotation processors use visitors to scan classes, fields, and annotations.
• ANTLR Parse Trees: Parsers generate parse-tree visitors allowing developers to traverse grammar nodes without modifying grammar definitions.

Pros and cons

When not to use it

Do not use Visitor if the hierarchy of element classes is constantly changing and new element classes are added frequently. In that scenario, the maintenance burden of updating all visitors outweighs the benefits.

Related patterns

Interview questions

Why is Double Dispatch required in the Visitor pattern? Because languages like Java use single dynamic dispatch (based on receiver runtime type, but argument compile-time type). Calling element.accept(v) ensures the first dispatch selects the concrete element's method, which then executes the second dispatch calling v.visit(this) with its exact concrete type.

What is the primary drawback of the Visitor pattern? Adding a new element type to the hierarchy breaks all existing visitor classes, requiring every visitor to implement a new visitNewElement() method.

How does Java 21's pattern matching switch replace the Visitor pattern? Sealed interfaces define a finite set of subtypes. A pattern-matching switch expression allows external functions to match against all concrete types exhaustively, providing compiler safety without double dispatch boilerplate.

Can a Visitor maintain state during traversal? Yes. Unlike element methods, a Visitor instance is stateful across the traversal, allowing it to aggregate totals (like word counts, total prices, or syntax error lists).