Objetos que notifican sus cambios de propiedades (2/3): Publish and subscribe

Nota: Este post es el segundo post de la serie Objetos que notifican sus cambios de propiedades.

En el post anterior vimos como configurar Unity para que no tener que añadir código adicional para implementar la interfaz INotifyPropertyChanged. En este post quiero hablaros de un patrón que se utiliza mucho cuando hablamos de aplicaciones complejas: el patrón del publicador – suscriptor. En este patrón tenemos básicamente dos conceptos:

1. El publicador: Cuando un objeto quiere notificar algo al respecto de su estado, se limita a publicar un mensaje con la información deseada.
2. El suscriptor: Los subscriptores reciben todos aquellos mensajes a los que están suscritos, con independencia de quien los haya publicado.

Este patrón se diferencia del modelo de eventos estándard de .NET, en que para realizar una suscripción a un tipo de mensaje no es necesario tener referencia alguna a quien pueda publicar este mensaje. En el sistema de eventos no és así: si quiero recibir información sobre el click de un botón, debo tener una referencia a este botón, para poder registrar la función gestora del evento:

button1.Click += new EventHandler(button1_Click);

Este modelo de eventos directos tiene sus limitaciones y da en Winforms bastantes quebraderos de cabeza (especialmente cuando tenemos un formulario con un usercontrol formado por varios usercontrols que a su vez están formados por más usercontrols y queremos propagar un evento del usercontrol  más interno al formulario). Es cierto que WPF introduce dos mejoras interesantes como los routed events (que ayudan precisamente a solventar este problema de usercontrols anidados) y los commands, pero ninguno de ambos mecanismos ofrece la misma flexibilidad que el modelo de publicación – suscripción.

Créeme: si desarrollas una aplicación compleja, ya sea en winforms o en WPF, te beneficiará mucho el uso de un modelo de publicación – suscripción (no en vano tanto CAB+SCSF como PRISM incorporan uno).

Vamos a ver como podemos implementarnos uno que, aunque sencillito, sea lo suficientemente funcional…

1. El notificador de mensajes

Lo primero que debemos crear es el notificador de mensajes, es decir el objeto que usamos para publicar un mensaje y el que usamos también para informar a que tipo de mensajes queremos suscribirnos.

El notificador de mensajes va a tener esta interfaz:

public interface ICommandNotifier
{
    /// <summary>
    /// Devuelve la lista de los commands actuales. Los commands se
    /// añaden automáticamente cuando se realiza un publish de cualquier
    /// tipo nuevo.
    /// </summary>
    IEnumerable<Type> Commands { get; }
    /// <summary>
    /// Añade una suscripción al tipo de command TPayload
    /// </summary>
    /// <typeparam name="TPayload">Tipo de command al que nos suscribimos</typeparam>
    /// <param name="func">Acción a ejecutar cuando se publique el command</param>
    /// <param name="filterFunc">Método que se evalúa sobre el payload para determinar
    /// si el command se pasa o no al suscriptor.</param>
    /// <returns>Token de suscripción</returns>
    SubscriptionToken Subscribe<TPayload>(Action<TPayload> func, Func<TPayload, bool> filterFunc);

    /// <summary>
    /// Publica un command. El tipo de command es el tipo de la clase del payload.
    /// </summary>
    /// <param name="payload">Payload (datos) del commanad</param>
    void Publish(object payload);

Básicamente sólo tiene un método para suscribirse a un determinado tipo de mensajes y otro método para publicarlos. Una implementación más compleja nos permitiría también eliminar suscripciones (es decir cuando ya no me interesa seguir recibiendo notificaciones de determinados commands)… pero eso lo dejamos como ejercicio 🙂

La implementación tampoco es excesivamente compleja (no pongo el código aquí, ya que lo tenéis en el zip que adjunto al final del post). Básicamente lo que hace es:

1. Mantiene una lista de todos los tipos de mensajes que se hayan lanzado. Lo que determina si un mensaje es de un tipo u otro es su clase (en la implementación una lista de objetos CommandInfo).
2. Por cada mensaje de esa lista mantiene una lista con todos los suscriptores (en la implementación objetos de la clase AllTimeSubscriber).
3. Por cada suscriptor de cada mensaje mantiene básicamente dos delegates:
   1. El delegate que sirve para decidir si se envía este mensaje a este suscriptor (parámetro filterFunc del método Subscribe)
   2. El delegate que debe invocarse en el suscriptor (parámetro func del método Subscribe).

Sólo un apunte: el notificador de mensajes vamos a registrarlo en Unity como un singleton, eso significa que existirá sólo uno y que estará vivo durante toda la ejecución del programa. Por lo tanto, si guardamos directamente los delegates en el notificador de mensajes, impedirá al garbage collector actuar sobre los suscriptores (recordad que un delegate mantiene una referencia a un objeto en concreto y a un método). Para solucionar esto me he creado una clase, que he llamado WeakDelegate, que tiene la misma información que un delegate, pero usa una WeakReference para apuntar al objeto (el suscriptor) y de esta manera permitir actuar al garbage collector. Recordad: siempre que guardeis referencias en un singleton considerad el uso de WeakReference!

2. Cambiar la implementación de nuestro handler

Una vez tenemos un notificador de mensajes, sólo debemos cambiar la implementación de nuestro ICallHandler (clase AutoPropertyChangedHandler) de Unity, para usar dicho notificador. Para ello en el método Invoke en lugar de llamar al método RaiseEvent (para lanzar el evento PropertyChanged) como hacíamos en el post anterior, vamos a usar el notificador para publicar un mensaje de tipo PropertyChangedCommand:

// Si el setter no produce excepción, publicamos un command de tipo PropertyChangedCommand
if (raiseEvt && msg.Exception == null)
{
    cmdNotifier.Publish(new PropertyChangedCommand(propName, input.Target));
}

La clase PropertyChangedCommand es una clase que nos hemos creado nosotros que no hace nada más que guardar el nombre de la propiedad que ha cambiado y el objeto sobre el cual ha cambiado la propiedad.

Como recibe la clase AutoPropertyChangedHandler el notificador de mensajes? Pues se le pasa en el constructor:

public AutoPropertyChangedHandler(ICommandNotifier cmdNotifier)
{
    this.cmdNotifier = cmdNotifier;
}

Ahora sólo debemos modificar la clase AutoPropertyChangedAttribute para que cuando cree el objeto AutoPropertyChangedHandler  le pase el notificador de mensajes. La forma más fácil es aprovechar que en AutoPropertyChangedAttribute tenemos acceso a Unity, para devolver el objeto AutoPropertyChangedHandler usando Resolve y que de esa manera Unity inyecte el notificador de mensajes:

public override ICallHandler CreateHandler(IUnityContainer container)
{
    return container.Resolve<AutoPropertyChangedHandler>();
}

3. El suscriptor

Finalmente nos queda crear el suscriptor. Los suscriptores son clases normales que usan el notificador de mensajes para suscribirse a tipos de mensajes. P.ej. el siguiente suscriptor se suscribe a los mensajes cuyo tipo sea PropertyChangedCommand:

public Suscriptor(ICommandNotifier cmdNotif)
{
    cmdNotif.Subscribe<PropertyChangedCommand>(this.DoPropertyChangedCommand, this.CanDoPropertyChangedCommand);
}

private void DoPropertyChangedCommand(PropertyChangedCommand payload)
{
    Console.WriteLine("Propiedad {0} modificada", payload.PropertyName);
}

private bool CanDoPropertyChangedCommand(PropertyChangedCommand payload)
{
    bool retVal = !payload.PropertyName.Equals("Name");
    Console.WriteLine("CanDoPropertyChanged con prop {0} devuelve {1}", payload.PropertyName, retVal);
    return retVal;
}

Fíajos en la función CanDoPropertyChangedCommand: esta función se evalúa cada vez que alguien publica un command y sólo en el caso que devuelva true se ejecutará la función DoPropertyChangedCommand que es la que “procesa” el mensaje. En este caso, este suscriptor está interesado en recibir todos los cambios de calquier propiedad excepto “Name”.

Finalmente sólo nos queda crear un suscriptor y probar el código. En el método Main() tengo:

container.RegisterType<ICommandNotifier, CommandNotifier>(new ContainerControlledLifetimeManager());
A2 a2 = container.Resolve<A2>();
Suscriptor subs = container.Resolve<Suscriptor>();
a2.Name = "edu";
a2.Edad = 10;
// Registramos el notificador como singleton
container.RegisterType<ICommandNotifier, CommandNotifier>(new ContainerControlledLifetimeManager());
// Creamos un A2...
A2 a2 = container.Resolve<A2>();
// ... y un suscriptor
Suscriptor subs = container.Resolve<Suscriptor>();
a2.Name = "edu";
a2.Edad = 10;

Y listos! Sí lo ejecutais veréis que la salida es:

CanDoPropertyChanged con prop Name devuelve False
CanDoPropertyChanged con prop Edad devuelve True
Propiedad Edad modificada

Ya tenemos implementado nuestro propio publicador-suscriptor!

Os dejo un zip con todo el código (en skydrive).

Un saludo!