Sé que este es un territorio muy transitado, pero tengo una pregunta específica... lo prometo.

Habiendo pasado muy poco tiempo en el mundo orientado a objetos y tipificado estáticamente, recientemente me encontré con este patrón de diseño mientras leía Crafting Interpreters . Si bien entiendo que este patrón permite un comportamiento extensible (métodos) en un conjunto de tipos (clases) existentes bien definidos, no entiendo la caracterización como una solución al problema del envío doble, al menos no sin algunos supuestos adicionales . Lo veo más como una compensación del problema de la expresión , donde intercambias tipos cerrados por métodos abiertos.

En la mayoría de los ejemplos que he visto, terminas con algo como esto (robado descaradamente de los increíbles patrones de diseño de Clojure )

 public interface Visitor { void visit(Activity a); void visit(Message m); } public class PDFVisitor implements Visitor { @Override public void visit(Activity a) { PDFExporter.export(a); } @Override public void visit(Message m) { PDFExporter.export(m); } } public abstract class Item { abstract void accept(Visitor v); } class Message extends Item { @Override void accept(Visitor v) { v.visit(this); } } class Activity extends Item { @Override void accept(Visitor v) { v.visit(this); } } Item i = new Message(); Visitor v = new PDFVisitor(); i.accept(v);

Aquí tenemos un conjunto de tipos (Mensaje y Actividad) que presumiblemente están cerrados o cambian con poca frecuencia, y un conjunto de métodos que queremos que estén abiertos para la extensión (los Visitantes). Ahora, donde me confundo es que en la mayoría de los ejemplos, mostrarán cómo puede implementar otros visitantes sin tocar las clases existentes, por ejemplo, algo como esto:

 public class XMLVisitor implements Visitor { @Override public void visit(Activity a) { XMLExporter.export(a); } @Override public void visit(Message m) { XMLExporter.export(m); } }

y luego hacer una alusión manual a que esto es "doble despacho", que no lo es. Aquí se accept envíos dinámicos en el subtipo de Item , pero dentro se accept los métodos de visit que se envían estáticamente al visitante pasado a través de la sobrecarga de métodos. Por lo tanto, tenemos un envío único en Item , y luego el "segundo" envío estático dentro de accept se trata realmente de seleccionar un comportamiento (método) para llamar con ese tipo de Item . Solo se envía un "tipo", no dos: el segundo es un comportamiento.

Cuando pienso en envío doble, pienso en una función que envía en el tipo de dos argumentos. Un comportamiento, dos tipos.

 export(Activity,XML) export(Activity,PDF) export(Message,XML) export(Message,PDF)

Para mí, esto es sutilmente diferente al patrón de visitante que permite que cualquier conjunto de comportamientos se extienda a las clases existentes, pero esos comportamientos no necesariamente representan todos el mismo comportamiento como en los cuatro ejemplos de export anteriores; pueden ser cualquier cosa. Si agregamos otro Visitante, puede representar una exportación, pero también podría no ser así. Desde la capa API, solo está llamando a métodos de accept y confiando en que el Visitante pasado hace lo que quiere, sea lo que sea.

¿Estoy viendo esto de la manera incorrecta?