Les bases de la Programmation Orientée Aspect
Crosscutting
Crosscutting
Nous allons utiliser un premier exemple simple pour mettre en évidence le phénomène de crosscutting. Pour cela, nous allons partir de la situation suivante :
Nous sommes en présence de deux classes « Line » et « Point » sur lesquelles on peut effectuer des opérations de déplacement dans un plan. Nous souhaitons par ailleurs garder une trace des appels de méthodes et des derniers déplacements d'un objet. On peut clairement voir le phénomène de crosscutting. En effet, nous retrouvons dans nos deux classes des traitements communs qui viennent s'entrelacer au reste des exigences que représentent nos objets.
Le but de la Programmation Orientée Aspect va être de sortir ces deux aspects de l'implémentation de nos classes pour arriver dans la situation suivante :
Nous avons maintenant deux types d'éléments au sein de notre système :
- Les composants : ils représentent les exigences qui peuvent être clairement encapsulé dans un objet (ex : système de connexion à une base de données).
- Les aspects : ils représentent en général les exigences non-fonctionnelles ne pouvant pas être encapsulées par un seul objet (ex : sécurité, performance).
Un peu de code
Nous allons maintenant visualiser en terme de code les changements que cela apporte. Pour cela, nous allons utiliser AspectJ qui permet de faire de la Programmation Orientée Aspect en Java. Nous reprenons tout d'abord nos deux classes avant la création des deux aspects :
On peut facilement repérer nos deux aspects au sein de nos classes. En bleu nous avons notre système de log utilisant de simple println et en rouge notre MoveTracker qui permet de sauvegarder les derniers déplacements effectués.
Nous allons maintenant créer deux aspects qui permettront d'effectuer les mêmes opérations :
Une fois nos deux aspects créés, nous pouvons nettoyer nos classes principales pour ne garder que le code métier :
Conséquences
Avec ce premier exemple, nous avons pu mettre en évidence le phénomène du crosscutting, mais quels sont les véritables conséquences de ce phénomène :
- Traçabilité difficile : les différentes exigences d'un logiciel deviennent difficilement identifiables dans l'implémentation.
- Diminution de la productivité : la présence de plusieurs exigences non-fonctionnelles dans un objet risque de perdre le développeur et de lui faire passer trop ou pas assez de temps sur un aspect « accessoire » d'un objet.
- Diminution de la réutilisation du code : dans la Programmation Orientée Aspect, les exigences non-fonctionnelles étant incluses dans plusieurs objets, il est difficile de réutiliser le code de ces aspects dans tout autre projet, car il est trop imbriqué/lié dans nos objets.
- Diminution de la qualité du code : la modification d'un aspect doit être répercutée sur toutes les classes concernées, il est très vite possible d'oublier une classe et de faire apparaître des bugs.
- Maintenance et évolutivité du code difficile : lors de l'évolution d'un système, on peut modifier de nombreuses classes. Modifier chaque classe pour répercuter les modifications souhaitées peut conduire à des incohérences.
