Visitor: New Operations Without Changing Classes

Why this matters

Imagine a document model with Circle, Rectangle, and Triangle. You need to add JSON export, XML export, and SVG rendering. Adding each operation as a method on every class violates the Open/Closed Principle — you're modifying stable code. The Visitor pattern externalizes operations: a JSONExportVisitor knows how to handle every shape; shapes only need to call accept(visitor). Adding a new export is a new class, not a change to existing ones.

Imagina un modelo de documento con Circle, Rectangle y Triangle. Necesitas añadir exportación JSON, exportación XML y renderizado SVG. Añadir cada operación como método en cada clase viola el Principio Abierto/Cerrado — estás modificando código estable. El patrón Visitor externaliza las operaciones: un JSONExportVisitor sabe cómo manejar cada forma; las formas solo necesitan llamar a accept(visitor). Añadir una nueva exportación es una nueva clase, no un cambio a las existentes.

✗ The problem

✓ The solution

Double dispatch in disguiseDoble despacho disfrazado

Visitor is the classic solution to the "double dispatch" problem — dispatching based on the types of two objects (visitor type and element type). When circle.accept(jsonVisitor) calls jsonVisitor.visitCircle(this), the language resolves both the element's type (Circle) and the visitor's type (JSONExportVisitor). Compiler AST walkers, expression evaluators, and document transformers all use this technique extensively.

Visitor es la solución clásica al problema de "doble despacho" — despachar basándose en los tipos de dos objetos (tipo visitor y tipo elemento). Cuando circle.accept(jsonVisitor) llama a jsonVisitor.visitCircle(this), el lenguaje resuelve tanto el tipo del elemento (Circle) como el del visitor (JSONExportVisitor). Los recorridos de AST de compiladores, evaluadores de expresiones y transformadores de documentos usan esta técnica extensivamente.