Alt.net paris #14: compte rendu AOP

Posté par jb dans Comptes Rendus Paris | 2 responses so far

La dernière présentation du groupe s’est déroulée mercredi dernier, dans une salle mise à disposition par FastConnect, et c’était Romain qui officiait.

L’AOP étant un sujet qui me tient à cœur, et ayant traversé la France (presque) pour l’occasion, autant dire que j’avais quelques attentes quant à cette session.

Résumons pour les pressés : c’était bien, il va falloir revenir. Pour les moins pressés, détaillons le déroulement de cette dernière soirée alt.net à Paris.

Romain étant un des membres originels d’alt.net à Paris, il était temps qu’il monte sur scène pour nous parler d’un sujet qui visiblement lui tient à cœur, la programmation orientée aspect. Les intéressés peuvent consulter son blog, qui contient quelques articles dédiés à cette pratique.

Un rapide sondage nous a montré que si beaucoup de personnes avaient déjà entendu parler d’AOP, peu savaient vraiment de quoi il en retournait, et encore moins utilisaient de l’AOP pour des applications en production.

La présentation s’est déroulée autour de quatre points, ainsi que des démonstrations.

Le problème que tente de résoudre l’AOP.

Si l’OOP nous permet de résoudre élégamment une multitude de problèmes, force est de constater que dans certains cas, les moyens mis à disposition dans les langages OOP mainstream ne permettent pas de complètement isoler certaines responsabilités. Et même en refactorant au plus fin le code, on retrouve quand même des méthodes qui vont mélanger certaines responsabilités.

Romain donne l’exemple typique est celui du logging. On est intéressé par logger le comportement d’une couche applicative, mais avec les moyens standards de l’OOP, on finit par mélanger à un moment ou à un autre le code applicatif, et le code du logging.

C’est une problématique que l’on retrouve dans plusieurs cas. On pourrait citer la persistance des données, la sécurité, les transactions, l’internationalisation par exemple. Ce sont souvent des contraintes techniques. Le terme de fonctionnalité transverse est évoqué pour désigner ces cas.

Ce sont ces problèmes que tentent de résoudre l’AOP, en fournissant au développeur des moyens d’isoler ces différentes fonctionnalités.

Les concepts de l’AOP.

Tout comme l’OOP, l’AOP à son propre jargon. Romain a ainsi décrit les termes spécifiques suivants:

• Aspect: Fonctionnalité transverse.
• Advice: Le code de l’aspect.
• Joinpoint: Point de jonction d’un aspect, c’est l’endroit logique où va venir se greffer l’aspect. Des exemples de joinpoint : entrée ou sortie de méthode, lecture ou écriture d’un champ, levée d’une exception, instantiation d’un object.
• Pointcut: Ensemble de joinpoint appliqués à un programme. Par exemple, l’ensemble des méthodes de la classe Foo.
• Weaver (tisseur): En l’absence de support de l’AOP au niveau du langage, c’est l’outil qui va tisser les advices aux pointcuts (et ouais).

Les techniques mises en oeuvre dans l’AOP.

Romain s’est ensuite attaché à expliquer les différents moyens de décrire les joinpoints et les pointcuts, en utilisant par exemple :

• Un langage particulier, à la AspectJ.
• Des méta-données, ou des annotations, quand la plateforme le permet.
• Des fichiers de configuration, que ce soit du XML, des DSL, ou autre fichier plat.
• Le code lui même, au travers d’une API spécifique au tisseur.

Puis il a décrit les différentes techniques de tissage:

• Statique, ou le tissage est réalisé avant l’exécution. Le tisseur peut opérer au niveau du code, ou au niveau du bytecode dans le cas de .net. On peut même imaginer interagir directement avec le compilateur, c’est possible dans le cas de boo par exemple.
• Dynamique, ou le tissage des aspects est réalisé pendant l’exécution. En .net on utilisera l’infrastructure de remoting, des dynamic proxies, ou encore des techniques plus évoluées comme l’API de profiling de la CLR.
• Hybride, qui utilise une combinaison des deux. Typiquement, l’infrastructure est tissée aux pointcuts, et les aspects y sont injectés à l’exécution.

Les outils .NET.

Malgré le fait qu’il existe des dizaines d’outils disponibles, Romain souligne le fait que très peu sont réellement utilisés dans des applications en production.

Pour ce qui est du tissage dynamique, outre la couche de remoting intégrée nativement au framework .net, il cite en particulier la fameuse librairie Castle.DynamicProxy pour faire de l’AOP dynamique, mais aussi LinFu.DynamicProxy, qui fait ici office d’outsider.

Détail intéressant, Romain a ensuite montré une relation entre les conteneurs IOC et l’AOP. Comme Spring.NET par exemple. En effet, les conteneurs IOC font souvent appel à des frameworks d’AOP pour résoudre leurs problématiques d’injection et d’interception. On évitera juste d’assimiler l’IOC à l’AOP, ce dernier couvrant potentiellement bien plus de besoins que les conteneurs IOC ne peuvent couvrir.

Du côté de l’AOP statique, il cite LinFu.Aop, encore assez jeune, mais surtout PostSharp, qui est à ce jour le framework (commercial cependant) le plus complet et le plus riche en terme de tissage statique.

Il nous a ensuite fait des démos de ces différents outils et techniques.

Conclusion

Une grosse session donc, avec une des plus fortes participations du groupe. La présentation haute en couleur du pince sans rire Romain a permis de lancer un débat qui s’est continué autour du buffet fourni par FastConnect. Et c’est ce qui continue de faire l’intérêt de ces sessions.

Les slides de cette session: