Par Félix-Antoine Bourbonnais, Mardi 29 Février
La programmation orientée aspect permet d’injecter des appels de méthodes (Logger.log() par exemple), avant/après/autour, par exemple des appels aux méthodes commençant par start.
AspectJ peut fonctionner en 2 modes : compile time (il faut utiliser son tisseur/weaver pour compiler) ou au runtime en utilisant un agent (ce qui peut permettre d’appliquer ses aspects sur du code tierce)
Spring AOP par contre est un cadre applicatif AOP pur java.
Parce l’AOP n’a pas décollé ?
- Mauvaises raisons et utilisations
- Complexité puisqu’on sait difficilement si le comportement de notre code va être modifié par des aspects
- Manque de support et d’intégration / manque de connaissance
- Trop de promesses
Outillage AspectJ :
- on peut construire avec Maven (attention à ne pas ré instrumenter le code avec du code coverage…)
- et on a une intégration dans Eclipse avec AJDT.
Il ne faut pas utiliser l’AOP pour cacher des problèmes de design ou pire, créer des problèmes de design.
Bonnes pratiques :
- garder les bonnes pratiques orientées objet
- ne pas oublier qu’un aspect va coupler du code (attention aux dépendances circulaires et la séparation des responsabilités du code)
- les classes sur lesquelles l’aspect va opérer, doivent elles en être « conscientes » (lisibilité, en utilisant des annotations)
Tester des aspects : un aspect n’est pas du code java pur : il est nécessaire de coder 1 « pot de miel » et vérifier que les appels des aspects ont bien été exécutés ET CECI aux bons endroits (pointcut)