El que más preocupaba a los autores de Design Patterns era el patrón "Visitante".
Es un "mal necesario", pero a menudo se usa en exceso y la necesidad a menudo revela un defecto más fundamental en su diseño.
Un nombre alternativo para el patrón "Visitante" es "Despacho múltiple", porque el patrón Visitante es con lo que termina cuando desea utilizar un lenguaje OO de despacho de un solo tipo para seleccionar el código que se utilizará según el tipo de dos (o más) objetos diferentes.
El ejemplo clásico es que tienes la intersección entre dos formas, pero hay un caso aún más simple que a menudo se pasa por alto: comparar la igualdad de dos objetos heterogéneos.
De todos modos, a menudo terminas con algo como esto:
interface IShape
{
double intersectWith(Triangle t);
double intersectWith(Rectangle r);
double intersectWith(Circle c);
}
El problema con esto es que ha acoplado todas sus implementaciones de "IShape". Ha insinuado que siempre que desee agregar una nueva forma a la jerarquía, también deberá cambiar todas las demás implementaciones de "Forma".
A veces, este es el diseño mínimo correcto, pero piénselo bien. ¿Su diseño realmente exige que se envíe en dos tipos? ¿Estás dispuesto a escribir cada una de las explosiones combinatorias de múltiples métodos?
A menudo, al introducir otro concepto, puede reducir la cantidad de combinaciones que realmente tendrá que escribir:
interface IShape
{
Area getArea();
}
class Area
{
public double intersectWith(Area otherArea);
...
}
Por supuesto, depende, a veces realmente necesitas escribir código para manejar todos esos casos diferentes, pero vale la pena hacer una pausa y pensar antes de dar el paso y usar Visitor. Podría ahorrarte mucho dolor más adelante.