Delegados en Xojo: no es lo que piensas

Uno de los conceptos en Xojo que más les cuesta coger a la mayoría de los usuarios, entre quienes también me incluía, no es otro sino el de los Delegados. En parte esto se debe a que la documentación oficial no haya sabido explicarlo de la mejor forma, o quizá sea porque choca con lo que entendemos por un Delegado en otros lenguajes de desarrollo, especialmente cuando la primera imagen que viene a tu cabeza es la de los patrones de diseño, y no es el caso.

En Xojo los Delegados tienen que ver últimamente con la implementación de un patrón de diseño, pero en realidad se trata de la definición de un tipo que, tal y como haríamos en otros lenguajes como el propio C o cualquiera de los actuales que manejen Bloques (Objective-C) o closures, definen la signatura de un método como tipo de dato, de modo que podamos pasar y recibir dicho método como parámetro.

Si lo deseas, también puedes pensar en los delegados como la definición de una variable que apunta a un método, de modo que podemos cambiar en cualquier momento su valor independientemente de cuál sea su clase. En definitiva, supone un modo de desacoplar la interfaz de la implementación.

La peculiaridad de los delegados en Xojo también tiene que ver con la forma de definir este tipo de dato en las clases de Xojo, dado que para ello se emplea en la ventana Inspector el mismo tipo de vista o plantilla que acostumbramos a utilizar en la definición de los propios métodos de clase. En cualquier caso, salvada esta confusión, quédate con la idea de que con un delegado estarás definiendo un nuevo tipo de dato que se corresponde con la signatura de un método.

Métodos como parámetros

¿Y para qué tanto lío de crear tipos de datos delegados? Pues por la inmensa flexibilidad que esto aporta. Ten en cuenta que cuando creas una jerarquía de clases tus objetos sólo pueden invocar los métodos de la misma clase o cualquier clase superior de la que derive dicho objeto; o bien aquellas que, en el caso de Xojo, también cumplan con las Interfaces asociadas (lo que vendría a ser Categorías o Protocolos en otros lenguajes de programación). Por tanto, a la hora de implementar ciertos patrones de diseño nos veríamos ante las restricciones impuestas por las reglas naturales de la programación orientada a objetos.

¿Cómo podrías crear entonces un patrón de diseño en el que invocases un método concreto en una serie de objetos, independientemente de cuál sea su Clase o Clase raíz? Ahí tienes la respuesta: delegados.

Al tratarse de una definición de tipo que nos permite pasar un método como parámetro, de lo único que tendremos que asegurarnos es que el método a utilizar en cualquiera de nuestros objetos receptores tenga la misma signatura declarada por el tipo delegado.

Así, la implementación típica en el uso de delegados sería la siguiente:

• La clase que actuará como emisor declara un delegado con una signatura de método determinada.

• La clase emisor también será responsable de implementar un método que se utilizará para registrar los objetos que deseen ser invocados cuando se cumpla una condición determinada. (Obviamente se utilizará un Array para almacenar las referencias.)

• Dicho método recibirá como parámetro el método a invocar en el objeto de destino con la correspondencia del tipo definido por el delegado.

• Cada uno de los objetos que quiera ser invocado se registrará utilizando dicho método, pasando la dirección del método que observe la signatura del delegado.

• Cada vez que se cumpla la condición, el objeto emisor llamará a cada uno de los métodos registrados como tipo delegado mediante Invoke.

Por supuesto, cuando definimos la signatura de un delegado podremos indicar los parámetros que tendrá dicho método y también el tipo del valor retornado (recuerda que se trata de definir la signatura de un método). Así, en las posteriores invocaciones también podremos pasar a cada uno de los métodos registrados los parámetros que esperen recibir para su funcionamiento.

En definitiva, cuando se coge finalmente el concepto de los delegados en Xojo, su uso proporciona una flexibilidad tremenda a la hora de implementar determinadas capacidades en nuestros desarrollos, manteniendo así un código que no sea interdependiente (mala cosa en la programación orientada a objetos), y sin la necesidad de tener que meternos en la construcción de verdaderas marañas de jerarquías de clase o clases e interfaces de clase. Un tremendo salvavidas.