Visitor

Visitor moves an operation out of the classes it works on into its own object, so new operations don't touch those classes. This page exports Pedal's fleet to CSV and plans its maintenance with two visitors, and shows the trade-off: new operations get cheap, new vehicle types get expensive.

1. The pain

Pedal's fleet has three kinds of vehicle: bikes, e-bikes and scooters. Other teams keep wanting new things done with the whole fleet: a CSV export for finance, a maintenance plan for the workshop, insurance values for the insurer. The first approach added a method for each to every vehicle class: to_csv(), maintenance(), insurance_value().

The vehicle classes, which describe what a bike is, filled up with export formats and insurance rules owned by other teams. Each new operation edited all three classes. The alternative, a function with if isinstance(v, EBike): … elif …, broke silently whenever someone forgot a branch.

2. The idea in one picture

Visitor moves an operation out of the classes it works on and into a separate object with one method per class: visit_bike(), visit_ebike(), visit_scooter(). Each vehicle has a single accept(visitor) method that calls the visitor method for its own type. That second call is the trick (called double dispatch): the right code runs for this vehicle type and this operation, with no type checks.

Visitor makes one kind of change cheap and the other expensive. Adding an operation is one new visitor; adding a vehicle type means a new method in every visitor. Choose it when the types are stable and the operations keep coming. In Python, functools.singledispatch or a match statement are lighter alternatives.

3. The roles

4. Before and after

One operation both ways (Python sketch; the full program is in section 5).

class EBike(Vehicle):
    def to_csv(self): ...           # finance
    def maintenance(self): ...      # workshop
    def insurance_value(self): ...  # insurer

# or, outside the classes:
def to_csv(v):
    if isinstance(v, Bike): ...
    elif isinstance(v, EBike): ...
    # Scooter forgotten: no error, no row

class EBike(Vehicle):
    def accept(self, v):
        return v.visit_ebike(self)

class CsvRow(VehicleVisitor):
    def visit_bike(self, b): ...
    def visit_ebike(self, e): ...
    def visit_scooter(self, s): ...

for vehicle in fleet:
    vehicle.accept(CsvRow())

Visitor trades cheap new types for cheap new operations. Pick it when operations change more often than types.

5. The code

Three vehicle classes, each with one accept() method, and two visitors. Each visitor has one method per vehicle type; the scooter on old firmware gets an update task.

from __future__ import annotations
from abc import ABC, abstractmethod


# ---- The element classes: stable, and each knows only how to accept a visitor. ----
class Vehicle(ABC):
    def __init__(self, vid: str) -> None:
        self.vid = vid

    @abstractmethod
    def accept(self, v: VehicleVisitor) -> str: ...


class Bike(Vehicle):
    def accept(self, v: VehicleVisitor) -> str:
        return v.visit_bike(self)


class EBike(Vehicle):
    def __init__(self, vid: str, battery: int) -> None:
        super().__init__(vid)
        self.battery = battery

    def accept(self, v: VehicleVisitor) -> str:
        return v.visit_ebike(self)


class Scooter(Vehicle):
    def __init__(self, vid: str, firmware: str) -> None:
        super().__init__(vid)
        self.firmware = firmware

    def accept(self, v: VehicleVisitor) -> str:
        return v.visit_scooter(self)


# ---- Visitors: one class per operation, with one method per vehicle type. ----
class VehicleVisitor(ABC):
    @abstractmethod
    def visit_bike(self, b: Bike) -> str: ...

    @abstractmethod
    def visit_ebike(self, e: EBike) -> str: ...

    @abstractmethod
    def visit_scooter(self, s: Scooter) -> str: ...


class CsvRow(VehicleVisitor):
    def visit_bike(self, b: Bike) -> str: return f"{b.vid},bike,"
    def visit_ebike(self, e: EBike) -> str: return f"{e.vid},e-bike,battery {e.battery}%"
    def visit_scooter(self, s: Scooter) -> str: return f"{s.vid},scooter,firmware {s.firmware}"


class MaintenanceTask(VehicleVisitor):
    LATEST_FIRMWARE = "2.2"

    def visit_bike(self, b: Bike) -> str:
        return f"{b.vid}: brakes and chain"

    def visit_ebike(self, e: EBike) -> str:
        return f"{e.vid}: brakes, chain, battery health ({e.battery}%)"

    def visit_scooter(self, s: Scooter) -> str:
        update = f", firmware update to {self.LATEST_FIRMWARE}" if s.firmware != self.LATEST_FIRMWARE else ""
        return f"{s.vid}: tyres{update}"


if __name__ == "__main__":
    fleet: list[Vehicle] = [Bike("B-17"), EBike("E-205", 84), Scooter("K-310", "2.1")]
    print("csv:\nid,kind,detail")
    for vehicle in fleet:
        print(vehicle.accept(CsvRow()))
    print("maintenance:")
    for vehicle in fleet:
        print(vehicle.accept(MaintenanceTask()))

// ---- The element classes: stable, and each knows only how to accept a visitor. ----
abstract class Vehicle {
  constructor(readonly vid: string) {}
  abstract accept(v: VehicleVisitor): string;
}

class Bike extends Vehicle {
  accept(v: VehicleVisitor): string { return v.visitBike(this); }
}

class EBike extends Vehicle {
  constructor(vid: string, readonly battery: number) { super(vid); }
  accept(v: VehicleVisitor): string { return v.visitEBike(this); }
}

class Scooter extends Vehicle {
  constructor(vid: string, readonly firmware: string) { super(vid); }
  accept(v: VehicleVisitor): string { return v.visitScooter(this); }
}

// ---- Visitors: one class per operation, with one method per vehicle type. ----
interface VehicleVisitor {
  visitBike(b: Bike): string;
  visitEBike(e: EBike): string;
  visitScooter(s: Scooter): string;
}

class CsvRow implements VehicleVisitor {
  visitBike(b: Bike) { return `${b.vid},bike,`; }
  visitEBike(e: EBike) { return `${e.vid},e-bike,battery ${e.battery}%`; }
  visitScooter(s: Scooter) { return `${s.vid},scooter,firmware ${s.firmware}`; }
}

class MaintenanceTask implements VehicleVisitor {
  static readonly LATEST_FIRMWARE = "2.2";
  visitBike(b: Bike) { return `${b.vid}: brakes and chain`; }
  visitEBike(e: EBike) { return `${e.vid}: brakes, chain, battery health (${e.battery}%)`; }
  visitScooter(s: Scooter) {
    const update = s.firmware !== MaintenanceTask.LATEST_FIRMWARE ? `, firmware update to ${MaintenanceTask.LATEST_FIRMWARE}` : "";
    return `${s.vid}: tyres${update}`;
  }
}

const fleet: Vehicle[] = [new Bike("B-17"), new EBike("E-205", 84), new Scooter("K-310", "2.1")];
console.log("csv:\nid,kind,detail");
for (const vehicle of fleet) console.log(vehicle.accept(new CsvRow()));
console.log("maintenance:");
for (const vehicle of fleet) console.log(vehicle.accept(new MaintenanceTask()));

import java.util.List;

public class Main {
    // ---- The element classes: stable, and each knows only how to accept a visitor. ----
    abstract static class Vehicle {
        final String vid;
        Vehicle(String vid) { this.vid = vid; }
        abstract String accept(VehicleVisitor v);
    }

    static class Bike extends Vehicle {
        Bike(String vid) { super(vid); }
        String accept(VehicleVisitor v) { return v.visitBike(this); }
    }

    static class EBike extends Vehicle {
        final int battery;
        EBike(String vid, int battery) { super(vid); this.battery = battery; }
        String accept(VehicleVisitor v) { return v.visitEBike(this); }
    }

    static class Scooter extends Vehicle {
        final String firmware;
        Scooter(String vid, String firmware) { super(vid); this.firmware = firmware; }
        String accept(VehicleVisitor v) { return v.visitScooter(this); }
    }

    // ---- Visitors: one class per operation, with one method per vehicle type. ----
    interface VehicleVisitor {
        String visitBike(Bike b);
        String visitEBike(EBike e);
        String visitScooter(Scooter s);
    }

    static class CsvRow implements VehicleVisitor {
        public String visitBike(Bike b) { return b.vid + ",bike,"; }
        public String visitEBike(EBike e) { return e.vid + ",e-bike,battery " + e.battery + "%"; }
        public String visitScooter(Scooter s) { return s.vid + ",scooter,firmware " + s.firmware; }
    }

    static class MaintenanceTask implements VehicleVisitor {
        static final String LATEST_FIRMWARE = "2.2";
        public String visitBike(Bike b) { return b.vid + ": brakes and chain"; }
        public String visitEBike(EBike e) { return e.vid + ": brakes, chain, battery health (" + e.battery + "%)"; }
        public String visitScooter(Scooter s) {
            String update = s.firmware.equals(LATEST_FIRMWARE) ? "" : ", firmware update to " + LATEST_FIRMWARE;
            return s.vid + ": tyres" + update;
        }
    }

    public static void main(String[] args) {
        List<Vehicle> fleet = List.of(new Bike("B-17"), new EBike("E-205", 84), new Scooter("K-310", "2.1"));
        System.out.println("csv:\nid,kind,detail");
        for (Vehicle vehicle : fleet) System.out.println(vehicle.accept(new CsvRow()));
        System.out.println("maintenance:");
        for (Vehicle vehicle : fleet) System.out.println(vehicle.accept(new MaintenanceTask()));
    }
}

Output (the same in all three languages)

csv:
id,kind,detail
B-17,bike,
E-205,e-bike,battery 84%
K-310,scooter,firmware 2.1
maintenance:
B-17: brakes and chain
E-205: brakes, chain, battery health (84%)
K-310: tyres, firmware update to 2.2

6. Try it

Which classes change?

Rows are vehicle types, columns are operations. Pick a design, then make a change and see which classes you'd edit.

Green: new code. Yellow: existing classes you must edit.

7. When not to use it

8. How it goes wrong

9. Remember it and say it

In an interview or code review

• Say which axis is stable: "Vehicle types rarely change; operations keep arriving, so each operation is a visitor."
• Explain double dispatch in one line: vehicle.accept(v) calls v.visit_ebike(self), so both the type and the operation choose the code.
• Name the cost: a new vehicle type adds a method to every visitor.
• Offer the lighter option: in Python, singledispatch or match; in Java 21, sealed types with pattern-matching switch.

10. Check yourself

11. Go deeper