I. Visitor — Behavioral Pattern

Visitor lets you define a new operation over a set of related types without modifying those types themselves. Each element type exposes a single Accept(visitor) method; the actual behavior lives entirely inside separate visitor objects, one per operation. Adding a new operation means writing a new visitor, not touching the elements at all.

This solves the problem of scattering unrelated operations — pricing, labeling, tax calculation, serialization — across the same set of types. Without Visitor, every new operation means adding a new method to every element type, so types that should only represent data end up accumulating logic for every consumer that ever needs to process them. Visitor moves each operation into its own object and uses double dispatch (element.Accept(visitor) calling back into visitor.VisitX(element)) so the right method runs for the right concrete type without a type switch.

It's the same shape as an AST node visited by a linter, a formatter, and a type-checker — each walks the same tree, but none of that logic lives inside the node types themselves.

II. Real-world Example

A coffee shop menu made of two item types, with two independent operations that need to run over both:

1. MenuItem (interface) — declares Accept(visitor Visitor) string, the single method every menu item must implement.

2. Visitor (interface) — declares one method per concrete element type: VisitDrink(drink Drink) string and VisitPastry(pastry Pastry) string.

3. Drink and Pastry — the concrete elements. Each one's Accept method does nothing but call the matching Visit method on whatever visitor it's given: drink.Accept(v) calls v.VisitDrink(drink).

4. PriceVisitor — implements both Visit methods to format a price string for each item type.

5. LabelVisitor — implements both Visit methods to format a category label instead.

Neither Drink nor Pastry contains any pricing or labeling logic — both live entirely in the visitors, and a third operation (say, a CalorieVisitor) could be added without changing Drink or Pastry at all.

III. Implementation

visitor.go

1package visitor
2
3type Visitor interface {
4	VisitDrink(drink Drink) string
5	VisitPastry(pastry Pastry) string
6}
7
8type MenuItem interface {
9	Accept(visitor Visitor) string
10}

items.go

1package visitor
2
3type Drink struct {
4	Name  string
5	Price float64
6}
7
8func NewDrink(name string, price float64) Drink {
9	return Drink{Name: name, Price: price}
10}
11
12func (d Drink) Accept(visitor Visitor) string {
13	return visitor.VisitDrink(d)
14}
15
16type Pastry struct {
17	Name  string
18	Price float64
19}
20
21func NewPastry(name string, price float64) Pastry {
22	return Pastry{Name: name, Price: price}
23}
24
25func (p Pastry) Accept(visitor Visitor) string {
26	return visitor.VisitPastry(p)
27}

visitors.go

1package visitor
2
3import "fmt"
4
5type PriceVisitor struct{}
6
7func (v PriceVisitor) VisitDrink(drink Drink) string {
8	return fmt.Sprintf("%s costs %.2f", drink.Name, drink.Price)
9}
10
11func (v PriceVisitor) VisitPastry(pastry Pastry) string {
12	return fmt.Sprintf("%s costs %.2f", pastry.Name, pastry.Price)
13}
14
15type LabelVisitor struct{}
16
17func (v LabelVisitor) VisitDrink(drink Drink) string {
18	return "Drink: " + drink.Name
19}
20
21func (v LabelVisitor) VisitPastry(pastry Pastry) string {
22	return "Pastry: " + pastry.Name
23}

main.go (usage)

1menuItems := []visitor.MenuItem{
2	visitor.NewDrink("Cappuccino", 4.25),
3	visitor.NewPastry("Muffin", 3.10),
4}
5labelVisitor := visitor.LabelVisitor{}
6priceVisitor := visitor.PriceVisitor{}
7
8for _, item := range menuItems {
9	fmt.Println(item.Accept(labelVisitor))
10	fmt.Println(item.Accept(priceVisitor))
11}

IV. Explain the example above

1. menuItems holds a Drink and a Pastry, both stored as the MenuItem interface — the loop has no idea which concrete type each one is.

2. For the first item (Drink{Cappuccino, 4.25}), item.Accept(labelVisitor) calls Drink.Accept, which calls labelVisitor.VisitDrink(d), returning "Drink: Cappuccino".

3. item.Accept(priceVisitor) on the same item calls priceVisitor.VisitDrink(d), returning "Cappuccino costs 4.25".

4. For the second item (Pastry{Muffin, 3.10}), Accept instead calls VisitPastry on each visitor, returning "Pastry: Muffin" and "Muffin costs 3.10".

Running it produces:

1*** Example Visitor ***
2Drink: Cappuccino
3Cappuccino costs 4.25
4Pastry: Muffin
5Muffin costs 3.10
6*** End of Visitor ***

The loop body never branches on whether item is a Drink or a Pastry — Accept handles routing to the correct Visit method internally. Swapping labelVisitor for a totally different visitor changes the entire operation without touching Drink, Pastry, or the loop.

V. Conclusion

Visitor earns its keep when you have a stable set of element types and a growing, open-ended set of operations that need to run over them. Keeping each operation in its own visitor means new operations never require touching the element types, and unrelated operations (pricing, labeling, tax, serialization) stay cleanly separated from each other.

The trade-off runs the other direction: adding a new element type means adding a method to the Visitor interface and updating every existing visitor to implement it. Visitor is a poor fit when element types change often but operations are stable — that's the exact inverse of what it optimizes for. For one or two operations that rarely change, methods directly on the element types are simpler than the double-dispatch machinery Visitor requires.

No pattern is universally superior.

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Source code on GitHub