Visitor pattern

Overview

The Visitor pattern lets you add new operations to a set of classes without modifying them. Each element class has an accept(visitor) method that calls visitor.visitX(this); a visitor implements one visit method per element type. New operations (export to JSON, compute tax, render) become new visitor classes.

Visitor is the mirror image of polymorphism: polymorphism makes adding types easy and operations hard; Visitor makes adding operations easy and types hard. It works best when the element hierarchy is stable (AST nodes, document elements, shapes) and operations keep growing. Double dispatch picks the right method based on both the visitor and the element.

When to use it

• Stable set of element types, many and growing operations.
• Operations that do not belong in the element classes (export, analysis).
• Traversing composite structures like ASTs or documents.

Where it shows up in interviews

Where it is used in real software

Key terms

Element

Class with accept(visitor).

Visitor

Interface with visit method per element type.

Double dispatch

Method chosen by both element type and visitor type.

Expression problem

Trade-off between adding types and adding operations.

How it works, step by step

1. 1
   Confirm the element types are stable

   Adding types later is costly.

2. 2
   Define the visitor interface

   visitCircle, visitRectangle...

3. 3
   Add accept() to each element

   visitor.visitCircle(this).

4. 4
   Implement one visitor per operation

   AreaVisitor, SvgExportVisitor.

5. 5
   Traverse composites

   Composite accept() visits its children.

Adding operations vs adding types

3 shapes (Circle, Rect, Triangle) and 3 operations

Choose Visitor when operations change more often than types.

Implementation

1public interface ItemVisitor<R> {2    R visitBook(Book b);3    R visitElectronics(Electronics e);4    R visitFood(Food f);5}6 7public interface CartItem { <R> R accept(ItemVisitor<R> v); }8 9public record Book(long priceCents) implements CartItem {10    public <R> R accept(ItemVisitor<R> v) { return v.visitBook(this); }11}12public record Electronics(long priceCents) implements CartItem {13    public <R> R accept(ItemVisitor<R> v) { return v.visitElectronics(this); }14}15public record Food(long priceCents, boolean prepared) implements CartItem {16    public <R> R accept(ItemVisitor<R> v) { return v.visitFood(this); }17}18 19// New operation without touching item classes20public final class TaxVisitor implements ItemVisitor<Long> {21    public Long visitBook(Book b) { return 0L; }22    public Long visitElectronics(Electronics e) { return e.priceCents() * 18 / 100; }23    public Long visitFood(Food f) { return f.prepared() ? f.priceCents() * 5 / 100 : 0L; }24}25 26long tax = List.<CartItem>of(new Book(1200), new Electronics(50000), new Food(800, true))27    .stream().mapToLong(i -> i.accept(new TaxVisitor())).sum();

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Using Visitor with an unstable hierarchy.

  Fix: Every new type breaks all visitors; prefer polymorphism.

• Heavy boilerplate for two operations.

  Fix: Simple methods on the classes may be clearer.

Interview questions

Practice problems