Lo que todo desarrollador debería saber sobre eventos en .NET Rodrigo Corral

LO QUE TODO DESARROLLADOR DEBERÍA SABER SOBRE EVENTOS EN .NET Nivel: Intermedio por Rodrigo Corral

La manera que las clases tienen de alertar a otras clases en los lenguajes orientados a objetos modernos es lanzar eventos. Una clase que no expone eventos hace mucho más ardua la tarea de los desarrolladores que la consumen a la hora de detectar cambios en su estado. Una clase sin eventos es una clase incomunicada.

En un sentido amplio se podría decir que toda clase que diseñemos y que mantenga un estado debería tener eventos. Si una clase mantiene estado es evidente que ese estado va a cambiar a lo largo del ciclo de vida de los objetos que instanciemos. Es evidente también que si no exponemos eventos, quien quiera enterarse de los cambios en el estado no tendrá más opción que preguntar activamente a nuestro objeto, en lugar de esperar plácidamente a recibir notificaciones. Nada nuevo bajo el sol, el viejo conocido patrón Observer.

Los eventos son imprescindibles y en .Net son ciudadanos de primera categoría (no ocurre así en otros lenguajes como C++). Aun así, no es extraño ver malas implementaciones de eventos. Es un tema que muchos desarrolladores creen conocer bien y sin embargo se ven a menudo errores relacionados con la mala implementación de este concepto. Y es que implementar bien un evento tiene más arte del que podría parecer y se pueden cometer más errores de los que uno puede pensar. Éstos varían en gravedad desde simplemente complicar la vida a las clases que deriven de la nuestra que expone eventos, hasta introducir condiciones de carrera difíciles de diagnosticar, pasando por simples incorrecciones de estilo. Lo peor de caso es que, por la propia naturaleza de estos errores, FxCop no es capaz de avisarnos de ellos.

Un evento simple Vayamos al grano y veamos la implementación más simple posible de un evento en .Net.

Los que hemos vivido los tiempos de .Net 1.0 y 1.1 sabemos que la palabra clave event solo es “azúcar sintáctico” que provoca que el compilador emita por nosotros un delegado y en los tiempos de 1.x nosotros mismos teníamos que declarar el tipo de delegado a mano. Se trata de un evento que ni siquiera implementa su propia clase de argumento para el evento. Sería algo como se muestra a continuación:

class Publisher

{

public event EventHandler SampleEvent;

public void FunctionThatProducesTheEvent()

{

SampleEvent(this, EventArgs.Empty);

}

}

¿Cuántos errores puede ver en esta implementación? Uno, dos, tres… si no les ves sigue leyendo.

¿Qué pasa si no hay nadie escuchando? Generalmente, en una conversación, para que se produzca una comunicación correcta debe haber una parte emitiendo y otra recibiendo. En .Net una clase que quiera escuchar los eventos de otra simplemente tiene que subscribirse a ellos:

class Subscriber

{

private Publisher _publiser = new Publisher();

public Subscriber()

{

_publiser.SampleEvent +=

new EventHandler(_publiser_SampleEvent);

}

void _publiser_SampleEvent(object sender, EventArgs e)

{

Console.Write("Habemus evento");

}

}

Como ya hemos comentado lo eventos se implementan, simplificando el asunto, como delegados. Simplificando otro poco podemos decir que los delegados son la versión orientada a objetos de los punteros a función. Básicamente la clase que declara el evento es declarando un tipo de puntero a función y un lugar en el que almacenar ese puntero. La clase que se subscribe proporciona la función que realmente se ejecutará mediante un puntero a la función durante la subscripción. Cuando la clase que lanza el evento hace la llamada al mismo (SampleEvent en el ejemplo), simplificando, está llamando a una función a través de un puntero. Por pura lógica si nadie se ha subscrito al evento dicho puntero será nulo, por lo tanto invalido, y en consecuencia recibiremos una fea excepción de tipo System.NullReferenceException.

La moraleja: siempre debemos comprobar que alguien se ha subscrito a nuestro evento antes de lanzarlo. Más simple no puede ser:

class Publisher

{

public event EventHandler SampleEvent;

public void FunctionThatProducesTheEvent()

{

//Comprobar que tenemos subcriptores

if (SampleEvent != null)

SampleEvent(this, EventArgs.Empty);

}

}

¿Qué pasa si hay varios hilos? El código anterior es más correcto. Pero aún tiene un error, además uno bastante sutil, que solo se manifestaría en situaciones en las que haya varios hilos de ejecución. Es una típica condición de carrera (o race condition). Estamos comprobando que tenemos alguien subscrito, en la siguiente instrucción de código estamos lanzando el evento. ¿Qué impide que la clase que estaba subscrita se haya de-suscrito entre medias? Nada. La moraleja: debemos asegurar que si alguien estaba escuchando, siga escuchando cuando nosotros digamos algo.

La solución pasa por manejar nuestra propia copia local de la lista de subscriptores. La implementación de esta solución es:

public void FunctionThatProducesTheEvent()

{

//Copia local de las subscripciones al evento para

//evitar la condición de carrera entre la comprobación de

//que hay subscriptores y el lanzamiento del evento.

//Aunque que todos se de-suscriban,

//nosotros tenemos la referencia.

EventHandler handler = SampleEvent;

//Comprobar que tenemos subcriptores

if (handler != null)

handler(this, EventArgs.Empty);

}

Aunque todos se de-suscriban nosotros seguimos teniendo una referencia. Las consecuencias de esta solución (que es la implementación correcta si seguimos el patrón de eventos de .Net) son varias:

1) Una clase que se haya de-suscrito de un evento, en un entorno multihilo, puede aun así recibirlo temporalmente. Si este comportamiento no es aceptable, tendremos que utilizar algún mecanismo de sincronización.

2) Si una clase está suscrita a un evento no podrá ser recolectada por el recolector de basura, pues aun quedarán referencias a ella. Esta es una forma muy sutil de fugar memoria de objetos en .Net: olvidar de-suscribir la clase de los eventos a los que está subscrita. Si esto no fuese así, no habría manera de garantizar que siempre hay alguien escuchando. Por lo tanto: si no de-suscribes tus objetos de los eventos a los que estén suscritos, pertenecientes a objetos con mayor tiempo de vida, el recolector de basura no puede llevárselos al otro mundo. Un patrón que funciona bastante bien es implementar IDisposable y de-suscribirnos de todos los eventos a lo que la clase se ha suscrito en el método Dispose.

¿Qué pasa si derivo de una clase que expone eventos? Supongamos que derivamos una clase de la clase base que expone eventos. Todos sabemos que el motivo para derivar una clase de otra es modificar o extender su comportamiento. Lógicamente uno de los aspectos que nos puede interesar variar del comportamiento de una clase es cómo se comportan sus eventos, qué ocurre cuando se lanzan, qué información acompaña al evento, etc…

Cuando se trata de modificar el comportamiento de un método de una clase base, podemos sobrescribir dicha función, el problema es que no podemos sobrescribir un evento. La solución al problema es simple: lanzar todos los eventos desde una función protegida y virtual, en lugar de directamente, de tal manera que una clase derivada pueda redefinir el comportamiento del evento a su gusto o incluso anular su lanzamiento sobrescribiéndola. La moraleja: debemos dar a las clases derivadas la oportunidad de modificar el comportamiento del lanzamiento del evento.

Además, con esa función damos a las clases derivadas la posibilidad de lanzar el evento si lo necesitan, simplemente invocando a la función que lanza el evento.

Con lo comentado anteriormente la implementación de nuestro evento quedaría como sigue:

class Publisher

{

public event EventHandler SampleEvent;

public void FunctionThatProducesTheEvent()

{

//Hacer algo aquí...

//Lanzar el evento

OnSampleEvent();

}

protected virtual void OnSampleEvent()

{

//Copia local de las suscripciones al evento para

//evitar la condición de carrera entre la comprobación de

//que hay subscriptores y el lanzamiento del evento.

//Aunque que todos se de-suscriban,

//nosotros tenemos la referencia.

EventHandler handler = SampleEvent;

//Comprobar que tenemos subcriptores

if (SampleEvent != null)

SampleEvent(this, EventArgs.Empty);

}

}

De esta manera, cualquier clase que derivase de la nuestra podría modificar el comportamiento del evento a su gusto simplemente sobrescribiendo la función OnSampleEvent. Una convención a tener en cuenta: si nuestro evento se llama XYZ la función virtual asociada debe llamarse OnXYX.

¿Qué pasa si además hay información asociada al evento? La firma de un evento declarado con EventHandler es:

public delegate void EventHandler(object sender, EventArgs e);

Con esta firma podemos detectar en la función que maneja el evento cual es el objeto que originó el evento -en el parámetro sender- e información asociada al evento -en el parámetro e de tipo EventArgs. Si vemos la definición de la clase EventArgs, veremos que es de nula utilidad, ya que no tiene campos que contengan información. El propósito de esta clase es servir como clase base para nuestros propios argumentos de evento.

Supongamos que quisiésemos que cuando salte nuestro evento, quien lo reciba, reciba además cierta información. Por ejemplo nos podría interesar saber a qué hora se produjo el evento. En esta situación lo primero es derivar una clase de la clase EventArgs que incluya la información que nos interesa:

class SampleEventArgs : EventArgs

{

readonly private DateTime _eventDateTime = DateTime.Now;

public DateTime EventDateTime

{

get { return _eventDateTime; }

}

}

Ahora lógicamente necesitamos cambiar la firma del delegado que manejará el evento. Para eso, desde .Net 2.0 o superior, tenemos una implementación genérica de la clase EventHandler que nos permite especificar el tipo de nuestro EventArgs. Es suficiente por tanto con cambiar la declaración del evento adecuadamente y corregir los errores de compilación. Con lo que la implementación de nuestra clase que expone eventos, quedaría definitivamente, como sigue:

class Publisher

{

public event EventHandler<SampleEventArgs> SampleEvent;

public void FunctionThatProducesTheEvent()

{

//Hacer algo aquí...

//Lanzar el evento

OnSampleEvent();

}

protected virtual void OnSampleEvent()

{

//Copia local de las subcripciones al evento para

//evitar la condición de carrera entre la comprobación de

//que hay subscriptores y el lanzamiento del evento.

//Aunque que todos se de-suscriban,

//nosotros tenemos la referencia.

EventHandler<SampleEventArgs> handler = SampleEvent;

//Comprobar que tenemos subcriptores

if (SampleEvent != null)

SampleEvent(this, new SampleEventArgs());

}

}

La moraleja: Si necesitamos transmitir información junto con el evento debemos derivar una clase de EventArgs contenedora de la información y usar la implementación genérica de EventHandler.

Una clase subscrita podría extraer fácilmente la información adicional asociada al evento:

class Subscriber

{

private Publisher _publiser = new Publisher();

public Subscriber()

{

_publiser.SampleEvent +=

new EventHandler<SampleEventArgs>(_publiser_SampleEvent);

}

void _publiser_SampleEvent(object sender, SampleEventArgs e)

{

Console.Write("Se lanzo el evento a las {0}",

e.EventDateTime);

}

}

Resumen de reglas para eventos No es extraño ver malas implementaciones de eventos.

Siempre debemos comprobar que alguien se ha suscrito a nuestro evento antes de lanzarlo y esta comprobación debe ser ‘thread safe’.

Una clase que se haya de-suscrito de un evento, en un entorno multihilo, puede aun así recibirlo momentáneamente.

Si nuestro evento se llama XYZ la función virtual asociada debe llamarse OnXYX.

Si no de-suscribes tus objetos de los eventos a los que estén suscritos, de objetos con mayor tiempo de vida, el recolector de basura no puede llevárselos al otro mundo.

Debemos dar a las clases derivadas la oportunidad de modificar el comportamiento del lanzamiento de los eventos y de lanzarlos si lo necesitan.

Si necesitamos transmitir información junto con el evento debemos derivar una clase de EventArgs contenedora de la información y usar la implementación genérica de EventHandler.

A que no pensabas que los eventos daban para tanto… ;-)

Acerca del autor Rodrigo Corral es MVP de ASP.NET y tutor de campusMVP. Trabaja como analista en Sisteplant, una empresa líder en el sector de las aplicaciones de gestión industrial. Anteriormente ha trabajado como responsable de desarrollo y analista-programador en Panda Software. Asimismo es formador en diversas materias tales como patrones de software, gestión de la configuración y Herramientas de diseño, etc.. Rodrigo es también Instructor Certificado de Microsoft (MCT). Es consultor y formador en Plain Concepts.

Acerca de campusMVP CampusMVP te ofrece la mejor formación en tecnología Microsoft a través de nuestros cursos online y nuestros libros especializados, impartidos y escritos por conocidos MVP de Microsoft. Visita nuestra página y prueba nuestros cursos y libros gratuitamente. www-campusmvp.com

Reconocimiento - NoComercial - CompartirIgual (by-nc-sa): No se permite un uso comercial de este documento ni de las posibles obras derivadas, la distribución de las cuales se debe hacer con una licencia igual a la que regula esta obra original. Se debe citar la fuente.