Double Dispatch

Double Dispatch

     En la ingeniería de software , el double dispatch  es una forma especial de multiple dispatch , y un mecanismo que envía una llamada de función a diferentes funciones concretas en función de los tipos de tiempo de ejecución de dos objetos que participan en la llamada. En la mayoría de los sistemas orientados a objetos , la función concreta que se llama desde una llamada de función en el código depende del tipo dinámico de un solo objeto y, por tanto, que se conoce como dispatch single.

Casos de uso

Double dispatch es útil en situaciones donde la elección de cálculo depende de los tipos de tiempo de ejecución de sus argumentos. Por ejemplo, un programador podría utilizar el double dispatch en las siguientes situaciones:

•          Ordenar un conjunto mixto de objetos: los algoritmos requieren que una lista de objetos se clasifican en un orden canónico. Decidir si un elemento está antes que otro elemento requiere el conocimiento de ambos tipos y, posiblemente, algún subconjunto de los campos.

•          Algoritmos adaptativos de colisión: por lo general requieren que las colisiones entre objetos diferentes se manejen de diferentes maneras. Un ejemplo típico es en un entorno de juego en el que la colisión entre una nave espacial y un asteroide se calcula de manera diferente de la colisión entre una nave espacial y una estación espacial.

•          Sistemas de gestión de personal: pueden enviar diferentes tipos de puestos de trabajo a personal diferente. 

•          Sistemas de control de eventos : que utilizan tanto el tipo de evento y el tipo del objeto receptor con el fin de llamar la rutina de manejo de eventos correcta.

      Cuando se llama a un método virtual en un objeto,  eso se considera de un solo envío, porque a qué método real se llama depende del tipo del objeto único.

     Para el envío doble, tanto el tipo de objeto como el tipo de argumento de método único se tienen en cuenta. Esto es como la resolución de sobrecarga del método, excepto que el tipo de argumento se determina en tiempo de ejecución en double dispatch en lugar de estáticamente en tiempo de compilación.

Veremos un ejemplo a continuación:

Supongamos que debemos modelar un juego de naves espaciales tipo Galaga, donde tenemos distintos tipos de objetos espaciales como ser Naves, Estaciones y Asteroides.

 Estos objetos pueden colisionar entre si y el resultado de dicha colisión depende particularmente de quienes son los objetos involucrados y del estado de los mismos.

ü  Si una nave colisiona con un asteroide la nave es destruida (vida = 0) y el asteroide disminuye su velocidad en 3 unidades.

ü  Si una nave colisiona con una estación a baja velocidad (velocidad < 10), entonces la nave se detiene (velocidad = 0) y la estación no sufre ningún cambio de estado.

ü  Si una nave colisiona con una estación a alta velocidad (velocidad >= 10), entonces la nave es destruida (vida = 0) y la estación disminuye su vida en 4 unidades.

Una solución trivial podría ser que cada objeto tenga un método “collideWith” en el que se verifique contra quien está chocando y se actúe en base a ello:

  

Las clases Asteroide y Estación tendrían métodos análogos.
Si bien esta solución funciona, resulta un poco “rústica” en términos de Orientación a Objetos porque viola algunos principios de diseño, entre ellos viola el principio abierto-cerrado, ya que en caso que aparecer un nuevo tipo de objeto (como por ejemplo Cometa) habría que modificar cada uno de los métodos CollideWith para contemplar los nuevos casos.

Es aquí donde el Double Dispatch nos propone una alternativa un poco más elegante. La idea es que cuando un objeto recibe una colisión, delega la resolución al otro objeto invocando a un método más concreto como se muestra en el siguiente fragmento de código:

Esta solución implica que cada clase tendrá un método collideWith por cada clase con la que pueda llegar a colisionar. En este caso particular donde tenemos 3 clases, tendremos 9 métodos (dependiendo del comportamiento particular que definamos para resolver la colisión podríamos tener tal vez algunos métodos menos).  En cierto modo esta solución también viola el principio abierto-cerrado, porque en caso de aparecer un nuevo tipo de objeto es necesario modificar todas las clases para agregar un nuevo método que resuelva la colisión aunque a diferencia de la solución anterior, aquí no modificamos un método existente, sino que agregamos un nuevo método, lo cual es menos rústico.

Finalmente la solución para esta situación entra en la categoría que Steve McConnell denomina Table-Driven methods (capítulo 18 de libro Code Complete). La idea es emular una tabla de métodos virtuales que es lo que usan algunos lenguajes a bajo nivel para resolver el late binding. Más concretamente lo que se hace es que cada objeto tenga una tabla o mejor dicho un diccionario (collisionMap) donde la clave es la clase contra la cual colisiona y el valor es un closure/lamba con la lógica a ejecutarse al colisionar contra ese tipo de objeto. Implementar esto en Smalltalk y/o Ruby es trivial, pero en Java tiene una vuelta de rosca extra, simplemente por la forma en que se implementan los lambdas en Java.

A la hora de agregar un nuevo tipo de objeto, esta solución requiere agregar una nueva entrada al collisionMap y un nuevo método si es que la interacción con este nuevo tipo de objeto es distinta a las ya existentes. Otro punto interesante de esta solución es la posibilidad de variar el comportamiento de cada instancia de la misma clase, ya que el collisionMappuede alterarse en tiempo de ejecución.

Existe otra manera de visualizar la implementación del double dispatch, combinándolo con el patrón de diseño Visitor(patrón de diseño de comportamiento), ya que el double dispatch es una técnica que permite añadir operaciones a las clases sin tener que modificarlas. La operación a ejecutar depende de la clase de petición (acepta) y del tipo de los dos receptores (Visitor, Elemento).

Por ejemplo: veamos un fragmento de un código implementando ambos patrones.

Declaración  de la interfaz Elemento:

Declaración  de la Clase Uno que se implementa de Elemento:

 Declaración  de la Clase Dos que se implementa de Elemento:

Declaración  de la Clase Tres que se implementa de Elemento:

Declaración  de la Clase ArribaVisitante que se implementa de Visitor:

Declaración  de la Clase AbajoVisitante que se implementa de Visitor:

En el siguiente video verán la explicación de como se implementa el Double Dispatch junto al patrón de diseño Visitor: