Emitiendo para toda la galaxia, ¿hay alguien ahí?: Lo que todo desarrollador debe saber sobre los eventos en .Net

La manera que las clases tiene 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 un clase incomunicada, que dirían los O’funk’illo.

En en 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 eventos. 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 que varían en gravedad desde complicar la vida a las clases que deriven de nuestra clase que expone eventos hasta introducir condiciones de carrera difíciles de diagnosticar, pasando por simples incorrecciones de estilo. Lo peor de caso, es que al contrario que en otras ocasiones, por la propia naturaleza de estos errores, FxCop no es capaz de avisarnos de ellos.

Vamos al grano. Veamos la implementación más simple posible de un evento en .Net 2.0, 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. En los tiempos de 1.0 y 1.1 nosotros teníamos que declarar el tipo de delegado ‘a manopla’. Se trata de un evento que ni siquiera implementa su propia clase de argumento del evento. Sería algo como sigue:

    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. Evidentemente esto no aplica si se trata de un grupo de mujeres. Pueden estar todas emitiendo, ninguna escuchando y aun así todas enterarse… misterios de la naturaleza.

En .Net un 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 la 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á, proporcionando el puntero a la función mediante la subscripción. Cuando la clase que lanza el evento hace la llamada al evento (SampleEvent en el ejemplo), simplificando, esta llamando a una función a través de un puntero. Es de lógica que si nadie se a subscrito 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 OnEvent;

 

        public void FunctionThatProducesTheEvent()

        {

            //Comprobar que tenemos subcriptores

            if (SampleEvent != null)

                SampleEvent(this, EventArgs.Empty);

        }

    }

¿Que pasa si hay varios hilos?

El código anterior es más correcto. Pero aun tiene un error, además un 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. 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 desuscrito 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 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 desuscriban, nosotros tenemos la referencia.

            EventHandler handler = SampleEvent;

 

            //Comprobar que tenemos subcriptores

            if (handler != null)

                handler(this, EventArgs.Empty);

        }

Aunque todos se desuscriban 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 desuscrito 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á subscrito 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 objetos en .Net: olvidar desuscribir 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. La moraleja: si no desuscribes 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. Un patrón que funciona bastante bien es implementar IDisposable y desuscribirnos de todos los eventos a lo que la clase se a subscrito en el método Dispose.

¿Qué pasa si derivo de un 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 no puede interesar modificar del comportamiento de una clase es como se comportan sus eventos, que ocurre cuando se lanzan, que información acompaña al evento, etc… Cuando se trata de una modificar el comportamiento de un método de una clase base, podemos sobreescribir dicha función, el problema es que no podemos sobreescribir 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 reescribiendo esta función. 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 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 desuscriban, 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 sobreescribiendo la función OnSampleEvent. La moraleja: si nuestro evento se llama XYZ la función virtual asociada debe llamarse OnXYX.

¿Qué pasa si además tengo algo que contar asociado 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 origino 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 nuestras 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 que 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 tenemos una implementación genérica de la clase EventHandler que nos permite especificar el tipo de nuestro EventArgs. Basta por tanto 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 desuscriban, 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);

        }

    }

Corolario:

  • No es extraño ver malas implementaciones de eventos.
  • Siempre debemos comprobar que alguien se ha subscrito a nuestro evento antes de lanzarlo y esta comprobación debe ser ‘thread safe’.
  • Una clase que se haya desuscrito 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 desuscribes 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 pensabais que los eventos daban para tanto… ;).

9 comentarios sobre “Emitiendo para toda la galaxia, ¿hay alguien ahí?: Lo que todo desarrollador debe saber sobre los eventos en .Net”

  1. @Carlos: Hay gente para todo, pero vamos, en un entorno Windows, usar pipes sería cuando menos, como tu comentas, un poco rarito. No se que decisiones de diseño les habrán llevado a usar pipes…

    Supongo que será por tratarse de un port de algo nacido en el mundo Unix, donde los pipes son un elemento natural.

    Un saludo y gracias por la información.

  2. Un poco por seguir hilando sobre el ejemplo y si no me equivoco, cuando derivas la clase EventArgs y añades campos o propiedades públicas a la clase derivada, hay que asegurarse de que estos sean serializables.

    De lo contrario puede ocurrir que no sea posible realizar la llamada al delegate con el que se ha suscrito alguno de los subscriptores.

    Es de suponer que solo ocurra cuando hay comunicación entre procesos (en la misma máquina o en diferentes máquinas), ya que en principio solo entonces parece necesaria la serialización.

    Sin embargo, este problema me pasó empleando eventos con WF, al desarrollar un CommunicationService.

  3. @Cristo:
    Tienes razón. Las clases personalizadas de EventArgs deben ser serializables. Lo que pasa es que como la clase EventArgs ya está marcada como Serializable, este atributo se hereda y si añadimos un campo no serializable a una clase serializable, recibimos un warning que advierte de la situación (no se si del compilador o de FxCop), por lo tanto, estamos protegidos. En cualquier caso, gracias por explicitarlo, es un detalle relevante.

    @Julio:
    Me alegro de que te haya servido.

    ¡Un saludo!

  4. Fantástico. El problema no es «aprender» a utilizar correctamente los eventos en .NET, sino que, al igual que con todo en este mundo, «comprender» es lo que realmente cuenta. Gracias a cómo has abordado el tema, comprendo perfectamente por qué hay que implementarlos de ese modo y no de otro. Gracias.

  5. Siempre se aprende algo nuevo, y eso que soy fanatico del uso de los eventos (razon por la cual no me trago lo de MVC) tan asi que implemente un sistema de navegacion en .NET totalmente basado en eventos, controles y el uso de un heredado de EventArgs como maleta de paso de informacion. Me encantaba!!

    El unico problema eran las dos circunstancias en que tenia que controlar que un PostBack no este siendo llamado en una misma ejecucion.

  6. Hola Rodrigo.
    Gran post. Seguro que ya nadie volverá a cometer errores al utilizar eventos.
    Sólo quería informarte de una errata en el tercer trozo/ejemplo de código:
    Al declarar el evento se llama OnEvent y al comprobar si hay suscriptores y lanzarlo se llama SampleEvent.
    Sé que es una tontería, pero igual evita alguna confusión.
    Saludos.

  7. Rodrigo:

    Este post me ha recordado el magnífico artículo de Ian marteens comparando cómo se gestionan los eventos en C# frente a cómo se hacen en Java, donde realmente no existen como tales y se tiene que hacer una implementación muy ineficiente y llena de problemas:

    http://www.marteens.com/trick53.htm

    Merece la pena darle un repaso siempre.

    Saludos

    JM

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *