Visitor

The four moving parts

Visitor splits the world into a stable side (the elements — our buildings) and a growing side (the visitors — one per operation):

• Element interface — declares exactly one method: accept(visitor). That's the building's front door. (Building with accept(v).)
• Concrete elements — House, Bank, CoffeeShop. Each implements accept with one line that names its own type: House.accept(v) calls v.visitHouse(this), Bank.accept(v) calls v.visitBank(this), and so on. This one line is the whole trick.
• Visitor interface — declares one visitX method per element type: visitHouse(h), visitBank(b), visitShop(s). It's the shape every operation must fill in: 'tell me what you do at each kind of building'.
• Concrete visitors — one class per operation: InsuranceAgent, SafetyAuditor, TaxAssessor. Each fills in all three visitX methods with that operation's logic. Adding an operation = adding one of these. Nothing else changes.

interface Visitor {                    // one visitX per element type
  visitHouse(h: House): void;
  visitBank(b: Bank): void;
  visitShop(s: CoffeeShop): void;
}

interface Building {
  accept(v: Visitor): void;            // the front door
}

class House implements Building {
  accept(v: Visitor) { v.visitHouse(this); }  // "I'm a House — use your House move"
}
class Bank implements Building {
  accept(v: Visitor) { v.visitBank(this); }   // "I'm a Bank — use your Bank move"
}
class CoffeeShop implements Building {
  accept(v: Visitor) { v.visitShop(this); }
}

// A new operation = a new class. The buildings above never change.
class InsuranceAgent implements Visitor {
  visitHouse(h: House)      { /* sell a home policy   */ }
  visitBank(b: Bank)        { /* sell theft cover     */ }
  visitShop(s: CoffeeShop)  { /* sell fire cover      */ }
}

Double dispatch, slowly

Here's the puzzle Visitor solves. You're holding a mixed street — a list typed as Building[] — and an agent. For each building you need to run the right combination of which building it is and which visitor is calling. That's a decision based on two runtime types at once, and ordinary method calls only ever pick a method based on one (the object you call it on). Visitor gets both by chaining two ordinary calls:

1. First dispatch — the building's door. You call building.accept(agent). The language's normal polymorphism ([[polymorphism]]) looks at the building's real runtime type and picks the right accept — House.accept, Bank.accept, whichever. At this moment the code knows it's standing inside a House.
2. Second dispatch — the visitor's move. That accept body is one line: v.visitHouse(this). Now polymorphism runs again, this time on the visitor's runtime type — if v is an InsuranceAgent you get the agent's visitHouse, if it's a SafetyAuditor you get the auditor's visitHouse. Two hops, and you've landed on exactly the (building type × visitor type) cell you needed.

The trade: cheap operations, expensive new element types

Visitor doesn't remove work — it moves it. Look at the grid of (element types × operations). Plain OO puts each operation as a method inside each element class: adding an operation means editing every element. Visitor flips the grid: adding an operation is one new visitor class and zero edits — but adding an element type (a fourth building, say Museum) now means editing every visitor: the Visitor interface gains visitMuseum, and InsuranceAgent, SafetyAuditor and TaxAssessor must each implement it. It's the exact mirror image. So the pattern pays off precisely when the element family is stable and the operations keep coming — and punishes you when it's the other way round.

Where you've already met it

• Compilers and ASTs — the classic home. A syntax tree has a fixed set of node types (IfNode, CallNode, LiteralNode…), but the operations never stop coming: a type-check visitor, a code-gen visitor, a lint visitor, a pretty-print visitor — each a separate class walking the same tree.
• Document exporters — one document tree of headings, paragraphs, tables and images; an HtmlExporter, PdfExporter and MarkdownExporter visitor each render the same nodes their own way, often walking a [[composite]] structure.
• File-system reports — walk one tree of files and folders with a total-size visitor, a virus-scan visitor, or a find-large-files visitor, without teaching File and Folder any of those jobs.

Reach for Visitor when operations outnumber element types

Visitor is a specialist's tool: spectacular in its niche, clumsy outside it. The niche has a precise shape:

• The element hierarchy is stable, the operations keep coming — a compiler's AST node types are fixed by the language grammar, but every release wants another pass (lint, optimize, format). New pass = new visitor, zero risk to the nodes.
• Unrelated operations are polluting the element classes — if Document nodes are accumulating toHtml(), toPdf(), wordCount(), spellCheck()… each with its own imports and helpers, visitors pull every operation into its own cohesive class and give the elements back a single responsibility ([[single-responsibility]]).
• One operation needs to act differently per concrete type across a mixed collection — you're iterating Building[] and instanceof/isinstance chains are spreading. Double dispatch replaces the whole chain with compiler-checked methods: forget one element type and the code doesn't compile, whereas a forgotten else if fails silently.