Visitor in Go

The Problem

Sometimes a structure is stable, but the operations over it keep growing. Reporting, export, auditing, and validation may all need to traverse the same catalog tree. If every new operation requires changing every node type, the structure becomes noisy and repetitive.

The Solution

Visitor moves each cross-cutting operation into a dedicated visitor object. In Go, nodes expose an Accept method and the visitor interface lists methods for each concrete node type. The tradeoff is explicitness: adding a new operation is easy, but adding a new node type requires updating the visitor contract.

Structure

• Visitor interface: Declares visit methods for each node type.
• Element interface: Nodes expose Accept.
• Concrete elements: Category and product nodes delegate to the visitor.
• Concrete visitor: PriceRollupVisitor accumulates totals across the tree.

Implementation

This example walks a small catalog tree and computes a price total without putting aggregation logic into every node type. The structure stays focused on domain data while the visitor carries the cross-cutting operation.

package main

type Visitor interface {
	VisitCategory(node CategoryNode)
	VisitProduct(node ProductNode)
}

type CatalogNode interface {
	Accept(visitor Visitor)
}

package main

type CategoryNode struct {
	Name     string
	Children []CatalogNode
}

type ProductNode struct {
	Name  string
	Price int
}

func (n CategoryNode) Accept(visitor Visitor) {
	visitor.VisitCategory(n)
	for _, child := range n.Children {
		child.Accept(visitor)
	}
}

func (n ProductNode) Accept(visitor Visitor) {
	visitor.VisitProduct(n)
}

package main

type PriceRollupVisitor struct {
	Categories []string
	Total      int
}

func (v *PriceRollupVisitor) VisitCategory(node CategoryNode) {
	v.Categories = append(v.Categories, node.Name)
}

func (v *PriceRollupVisitor) VisitProduct(node ProductNode) {
	v.Total += node.Price
}

package main

import "fmt"

func main() {
	fmt.Println("=== Visitor in Go ===")

	catalog := CategoryNode{
		Name: "Launch Kits",
		Children: []CatalogNode{
			ProductNode{Name: "Keyboard", Price: 12900},
			CategoryNode{
				Name: "Accessories",
				Children: []CatalogNode{
					ProductNode{Name: "Desk Mat", Price: 2500},
					ProductNode{Name: "Cable", Price: 900},
				},
			},
		},
	}

	visitor := &PriceRollupVisitor{}
	catalog.Accept(visitor)

	fmt.Println("categories:", visitor.Categories)
	fmt.Println("total:", visitor.Total)
}

Best Practices

• Use Visitor only when the node set is relatively stable and operations change more often.
• Keep the visitor contract explicit so it is obvious which node types must be handled.
• Pair Visitor with Composite when operations need to traverse a tree structure recursively.
• Avoid Visitor when simple methods on the nodes would be clearer.
• Be honest about the tradeoff: adding a new node type is more expensive with Visitor.

When to Use

• A stable object structure needs many evolving cross-cutting operations.
• You want to keep those operations out of the node types themselves.
• Traversal should stay strongly typed rather than reflection-driven.

When NOT to Use

• The structure changes frequently with new node types.
• One or two simple methods on the nodes would be clearer.
• The visitor ceremony would outweigh the benefit for a small model.