Codingly

J’ai ce billet dans mes drafts depuis un moment, et il serait peut-être bon de l’en sortir avant qu’il ne soit trop tard… Dans un post récent, je parlais de l’interface INotifyPropertyChanged, en donnant un exemple d’implémentation basée sur les lambda expressions et les expression trees qui permettait d’obtenir une solution fortement typée.

L’AOP peut également être une solution, et peut-être même le meilleur compromis pour peu que l’on en tire partie correctement. Suite à un commentaire de Jb, j’ai essayé de voir ce que pouvait donner l’utilisation d’un tisseur statique comme PostSharp dans ce cas précis.

J’avais déjà fait auparavant quelques tests satisfaisants avec DynamicProxy de Castle, qui est un, heu, tisseur dynamique. Les contraintes m’avaient semblées être assez fortes (toujours pour résoudre la problématique de INotifyPropertyChanged) :

• Nécessité de créer un proxy pour chaque instance d’objet bindé
• Interception uniquement possible sur les propriétés virtuelles
• Performances moyennes dues au caractère dynamique des interceptions

Cela dit, en terme de concision, c’est probablement la méthode la plus efficace puisqu’en créant un StandardInterceptor d’une dizaine de lignes on pouvait s’en sortir.

Revenons à PostSharp. J’ai été impressionné, vraiment, par cet outil. Sans passer trop de temps à expliquer son fonctionnement, puisque Gael Fraiteur l’a déjà fait, sachez que le framework est un static weaver (entre autres), qui intervient en temps que post-compiler pour inspecter et modifier le code IL des assemblies résultant de la compilation. Je vous invite à consulter les ressources mises à disposition par l’auteur sur le site, elles sont assez complètes. Dans le contexte de notre problématique (oui, les notifications m’obsèdent) les avantages du tissage en post-compilation sont les suivants :

• Pas de proxy à créer au runtime pour chaque instance
• Les types sur lesquels on désire tisser l’aspect « notification-des-changements » n’ont pas besoin de respecter une quelconque convention
• Une partie du travail peut être faite durant le build process, ce qui améliore les performances au runtime.

Illustrons par le code.

Voici mon POCO (je vous conseille d’imaginer le même avec 15 propriétés) :

    public class Person
    {
        private string name;

        public string Name
        {
            get { return this.name; }
            set { this.name = value; }
        }
    }

Voici ce que je cherche à obtenir, fonctionnellement, sans avoir à écrire le code de plomberie :

    public class Person : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        private string name;

        public string Name
        {
            get { return this.name; }
            set
            {
                if (this.name != value)
                {
                    this.name = value;
                    FirePropertyChanged("Name");
                }
            }
        }

        private void FirePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

En fait, voici ce que je cherche réellement à obtenir :

    [NotifyPropertyChanged]
    public class Person
    {
        private string name;

        public string Name
        {
            get { return this.name; }
            set { this.name = value; }
        }
    }

La différence avec la première version est subtile : un attribut NotifyPropertyChanged. Je veux que tout soit transparent au niveau de mon code client. Que des instances de Person puissent être créées, ajoutées à des sources de données, modifiées comme n’importe quelles autres instances, etc.

Donc, exit le proxying, exit l’interception dynamique : ceux qui y sont habitués ont déjà compris que ce n’était pas possible. C’est là que réside la force d’un tisseur comme PostSharp (ou AspectDNG) : ils rendent possible ce genre de choses, grâce à l’approche potentiellement troublante du tissage statique.

Pour la suite de l’article, je vais simplement vous montrer une solution, et la commenter. Il ne s’agit pas d’un tutorial – mais plutôt d’une pseudo-étude de cas ayant pour but de donner un bon aperçu des capacités de PostSharp. Et accessoirement d’apaiser mon obsession.

Le principe

Utiliser PostSharp est un peu moins intuitif qu’utiliser DynamicProxy. Je vais tenter de vous exposer le principe de base de la solution.

Que faut-il pour passer d’un POCO à un POCO qui supporte INotifyPropertyChanged :

1. Implémenter l’interface du même nom : INotifyPropertyChanged, et donc, fournir un event public ayant la signature suivante : public event PropertyChangedEventHandler PropertyChanged;
2. Intercepter les accès en écriture aux propriétés, pour déclencher cet évènement PropertyChanged. Dans l’exemple donné plus haut, on va même jusqu’à tester s’il est nécessaire de déclencher l’évènement en comparant la nouvelle valeur à l’existante.

Ce sont deux choses distinctes, bien qu’on ait souvent tendance à les associer, ne serait-ce que parce que c’est logique. Mais pour bien comprendre comment utiliser l’AOP, et plus particulièrement comment concevoir l’aspect que l’on va vouloir tisser grâce à PostSharp, c’est important. Car nous allons en fait utiliser un aspect composite, formé de plusieurs sous-aspects ayant chacun un but précis.

Interception des affectations des champs privés

Ce sous-aspect, de type OnFieldAccessAspect, a un rôle facultatif : il va vérifier que la valeur que l’on cherche à affecter à un champ est différente de la valeur existante. Cela permettra de savoir si l’on doit ou non déclencher l’évènement PropertyChanged.

Implémentation de INotifyPropertyChanged

Le but de ce sous-aspect et d’implémenter INotifyPropertyChanged. PostSharp propose un CompositionAspect qui, lorsqu’il est appliqué à un type, se charge de lui faire implémenter une interface donnée en utilisant la composition et la délégation.

Le POCO implémentera bien l’interface INotifyPropertyChanged, mais les abonnements/désabonnements à son évènement PropertyChanged seront interceptés et relayés à un composant (InnerNotifier ci-dessus) implémentant également INotifyPropertyChanged. Quelque chose du genre :

    public event PropertyChangedEventHandler PropertyChanged
    {
        add { this.innerNotifier.PropertyChanged += value; }
        remove { this.innerNotifier.PropertyChanged -= value; }
    }

Le CompositionAspect a donc deux tâches :

1. Définir quelle interface le POCO doit implémenter. Une petite idée ?
2. Fournir un composant qui se chargera de la réelle logique d’implémentation de l’interface, et qui, nous le verrons plus tard, offrira également un moyen de déclencher l’évènement PropertyChanged (méthode FirePropertyChanged ci-dessus)

Interception des appels aux setters des propriétés

Ce sous-aspect a pour mission de déclencher l’évènement PropertyChanged lorsqu’un setter est appelé et que le backing field a bien été modifié. Il doit donc interagir, d’une manière ou d’une autre, avec l’aspect précédent pour déclencher l’évènement.

Il est de type OnMethodBoundaryAspect selon l’API PostSharp.

Composition de l’aspect composite

Enfin, il faut l’aspect de haut niveau, qui agrège les sous-aspects de façon cohérente pour offrir la fonctionnalité désirée. PostSharp permet la définition d’aspects composites : il suffit de créer un CompoundAspect.

La solution

Si l’approche down-top correspondait plutôt bien à l’exposition du principe de fonctionnement, je crois qu’il est plus clair ici de partir du plus haut niveau pour découvrir l’implémentation de la solution proposée.

Et le point de départ, c’est l’attribut [NotifyPropertyChanged] dont on souhaitait décorer les POCO à tisser. En voici le code :

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
[MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]
public class NotifyPropertyChangedAttribute : CompoundAspect
{
    public override void ProvideAspects(object element,
                                        LaosReflectionAspectCollection collection)
    {
        var type = (Type)element;
        collection.AddAspect(type, new ImplementINotifyPropertyChangedAspect());

        BindingFlags lookupFlags = BindingFlags.Instance
                                 | BindingFlags.Public
                                 | BindingFlags.DeclaredOnly;
        foreach (PropertyInfo propertyInfo in type.GetProperties(lookupFlags))
        {
            if (propertyInfo.CanWrite)
            {
                MethodInfo setterInfo = propertyInfo.GetSetMethod();
                collection.AddAspect(setterInfo, 
                                     new FirePropertyChangedAspect(setterInfo.Name));
            }
        }

        lookupFlags = BindingFlags.Instance
                    | BindingFlags.NonPublic
                    | BindingFlags.DeclaredOnly;
        foreach (FieldInfo fieldInfo in type.GetFields(lookupFlags))
        {
            collection.AddAspect(fieldInfo, new InterceptFieldAffectationAspect());
        }
    }
}

C’est l’aspect composé lui-même, le CompoundAspect. Analysons-le un peu plus en détails :

• Il est lui-même décoré par des attributs définissant les cibles possibles de l’aspect. Ici, on vise les types. PostSharp permet aussi l’application d’aspects par multicasting, ce qui permet de tisser des aspects sans la moindre intrusion au niveau du code à instrumenter. Concrètement, on pourrait se passer d’appliquer manuellement notre attribut [NotifyPropertyChanged] sur chaque type, et définir à la place une règle déterminant quels sont les types sur lesquels appliquer l’aspect.
• La méthode ProvideAspects est exécutée lors de la post-compilation. Elle permet de définir quels sont les sous-aspects qui composent le CompoundAspect, et sur quoi ils s’appliquent. Chaque sous-aspect doit être ajouté avec le descripteur de sa cible. Nous allons retrouver les 3 types d’aspect sus-cités :
  • Le sous aspect ImplementINotifyPropertyChangedAspect est appliqué au type de l’élément que l’on tisse.
  • Le sous aspect FirePropertyChangedAspect concerne les setters du type. On en ajoute donc une instance pour chacun d’entre eux.
  • Enfin, le sous aspect InterceptFieldAffectationAspect concerne les champs du type. On en ajoute une instance pour chacun des champs privés du type.

Regardons à quoi ressemble le premier des sous-aspects :

[Serializable]
internal class ImplementINotifyPropertyChangedAspect : CompositionAspect
{
    public override object CreateImplementationObject(InstanceBoundLaosEventArgs eventArgs)
    {
        return new InnerNotifier(eventArgs.Instance);
    }

    public override Type GetPublicInterface(Type containerType)
    {
        return typeof (INotifyPropertyChanged);
    }

    public override CompositionAspectOptions GetOptions()
    {
        return CompositionAspectOptions.GenerateImplementationAccessor;
    }
}

Ca colle assez bien avec les explications précédentes, et le code est auto commenté. Le composant implémentant réellement l’interface INotifyPropertyChanged est un InnerNotifier dont voici la définition :

[Serializable]
internal class InnerNotifier : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    private readonly object eventSender;

    private bool shouldFirePropertyChanged;

    public InnerNotifier(object eventSender)
    {
        this.eventSender = eventSender;
    }
    
    public bool ShouldFirePropertyChanged
    {
        get { return this.shouldFirePropertyChanged; }
        set { this.shouldFirePropertyChanged = value; }
    }

    public void FirePropertyChanged(string propertyName)
    {
        if (this.PropertyChanged != null && this.shouldFirePropertyChanged)
        {
            this.PropertyChanged(this.eventSender, 
                                 new PropertyChangedEventArgs(propertyName));
        }
    }
}

Là encore c’est trivial : on implémente l’interface, et on expose une méthode publique permettant de déclencher manuellement l’évènement.

C’est d’ailleurs l’aspect FirePropertyChangedAspect qui s’en chargera :

[Serializable]
public class FirePropertyChangedAspect : OnMethodBoundaryAspect
{
    private InnerNotifier notifier;
    private readonly string propertyName;

    public FirePropertyChangedAspect(string propertyName)
    {
        this.propertyName = propertyName;
    }

    public override void OnSuccess(MethodExecutionEventArgs eventArgs)
    {
        if (this.notifier == null)
        {
            var composedInteface = eventArgs.Instance as IComposed<INotifyPropertyChanged>;
            if (composedInteface != null)
            {
                this.notifier =
                    composedInteface.GetImplementation(eventArgs.InstanceCredentials)
                    as InnerNotifier;
            }
        }

        if (this.notifier != null)
        {
            this.notifier.FirePropertyChanged(this.propertyName);
        }
    }
}

La méthode OnSuccess est une des méthodes qu’il est possible de surdéfinir sur un OnMethodBoundaryAspect. Dans le flow d’interception, elle sera invoquée au runtime lorsque l’appel à la méthode cible aura réussi, donc, après que ce dernier ait eu lieu. Si vous êtes encore à me lire, vous méritez que je vous épargne les détails d’implémentation de cette méthode, mais sachez au moins qu’on récupére le InnerNotifier ayant été tissé par l’aspect ImplementINotifyPropertyChangedAspect, et que l’on appelle sa méthode FirePropertyChanged pour déclencher l’évenement en lui passant le nom de la propriété concernée.

Note: Fouillez dans la doc de PostSharp au sujet de IComposed<T> si vous voulez plus de viande, mais en gros, c’est le moyen d’exposer le composant d’un CompositionAspect (ici, notre InnerNotifier) lorsque l’option CompositionAspectOptions.GenerateImplementationAccessor a été définie. (cf. méthode GetOptions dans ImplementINotifyPropertyChangedAspect)

OK. Et non, ce n’est pas terminé, il reste bien le dernier sous-aspect utilisé pour déterminer si l’évenement PropertyChanged sera lancé ou non. J’ai nommé, InterceptFieldAffectationAspect :

[Serializable]
public class InterceptFieldAffectationAspect : OnFieldAccessAspect
{
    private InnerNotifier notifier;

    public override void OnSetValue(FieldAccessEventArgs eventArgs)
    {
        if (this.notifier == null)
        {
            var composedInteface = eventArgs.Instance as IComposed<INotifyPropertyChanged>;
            if (composedInteface != null)
            {
                this.notifier =
                    composedInteface.GetImplementation(eventArgs.InstanceCredentials)
                    as InnerNotifier;
            }
        }
        if (this.notifier != null)
        {
            this.notifier.ShouldFirePropertyChanged =
                !eventArgs.ExposedFieldValue.Equals(eventArgs.StoredFieldValue);
        }
        base.OnSetValue(eventArgs);
    }
}

Dans la méthode OnSetValue :

• On récupère une fois de plus le InnerNotifier ayant été tissé par l’aspect ImplementINotifyPropertyChangedAspect
• Si la valeur affectée au champ est égale à la valeur existante, on empêche le déclenchement de l’évènement via la propriété ShouldFirePropertyChanged du notifier.

Et voilà.

En résumé

Hum, pas vraiment un résumé, mais plutôt la séquence ayant lieu au runtime lors de la modification d’une propriété d’un objet instrumenté :

1. On s’abonne à l’évenement PropertyChanged de l’objet : ce dernier propage l’abonnement à son InnerNotifier.
2. On affecte une valeur à la propriété : le setter est appelé, mais l’interception par FirePropertyChangedAspect n’aura lieu qu’à la sortie de ce dernier.
3. Dans le corps du setter, on affecte la valeur au backing field : c’est une affectation interceptée par l’aspect InterceptFieldAffectationAspect. Si la valeur affectée est différente de celle du champ, alors il autorise le InnerNotifier à déclencher l’évènement PropertyChanged via la propriété ShouldFirePropertyChanged. Sinon, il désactive l’InnerNotifier, toujours via la propriété ShouldFirePropertyChanged.
4. A la sortie du setter, on entre dans le code d’interception de l’aspect FirePropertyChangedAspect qui, via l’InnerModifier, déclenche l’évènement PropertyChanged. Ce dernier ne sera effectivement déclenché que s’il a été laissé actif par l’InterceptFieldAffectationAspect précédemment.

Quelques remarques pour les plus courageux désoeuvrés :

• L’implémentation n’est pas une référence, et la communication entre les différents sous-aspects via le InnerNotifier n’est pas quelque chose dont je suis particulièrement fier. Mais ma connaissance de PostSharp est trop limitée actuellement pour me permettre d’envisager quelque chose de plus élégant.
• La solution peut sembler fastidieuse, mais compte tenu des spécifications (assez virtuelles, j’avoue), elle offre un bon compromis au niveau des performances : 5 fois plus lente que sans AOP, mais 5 fois plus rapide qu’une solution à base de tissage dynamique. Environ. Update : Il semblerait que dans le cas de cette implémentation les performances soient les mêmes que celles qu’on pourrait obtenir avec un tisseur dynamique.
• Au niveau de l’utilisation, c’est la forme d’AOP la plus concise et la moins intrusive possible, donc celle qui offre potentiellement le meilleur niveau d’abstraction et le meilleur gain de productivité.
• Si vous avez des alternatives, avec ou sans PostSharp, je suis preneur, évidemment.

Cet article est probablement trop chiant pour être lu jusqu’au bout, et trop spécifique pour être utile, mais il me fallait un post pour le mois d’octobre. Haha.