Différents tisseurs open source existent. Ils implémentent une de ces deux stratégies. Les plus connus sont AspectJ, Spring AOP et Jboss AOP, Aspect Werkz.

Dans ce document, nous nous intéresserons en particulier à AspectJ (tissage statique), à Spring AOP et Jboss AOP (tissage dynamique).

III.    IMPLEMENTATION ASPECTJ

A la fois un langage et un outil (plugin, tisseur), il est considéré comme le plus complet permettant d’implémenter l’AOP. Il est aussi le plus utilisé des langages AOP.

AspectJ est une extension du langage JAVA. Il apporte une syntaxe de composition à la fois statique et dynamique permettant de fusionner les aspects fonctionnels avec les aspects techniques.

AspectJ permet donc, deux types de composition :

• Statique : elle permet de modifier le système (classes et interfaces) par ajout d’attributs, de méthodes, ou par ajout d’une gestion des avertissements (warnings) et des erreurs.
• Dynamique : permet d’ajouter de nouveaux comportements lors de l’exécution, d’étendre ou de remplacer certains traitements.

NB : Nous nous sommes basés sur AspectJ pour illustrer l’exemple de notre article (Chapitre suivant).

IV.    AOP PROGRAMMATION AVANCEE

Pour illustrer à la fois la puissance et la facilité d’utilisation des principes de la POA, nous avons choisi, à travers un exemple de gestion des droits, d’aborder l’implémentation d’un des design patterns. Il s’agit du patron « Proxy ». L’objectif est d’apprécier le raffinement que peut apporter la pratique de la programmation par aspect.

Rappel

Les design patterns ou patrons de développement sont des motifs standards complètement indépendants des langages de programmation. Ils sont de différents types (création, structure, comportement) et ne peuvent être utilisés que pour répondre à certaines problématiques particulières.

Les patrons sont de bons candidats à l’implémentation AOP car une partie du code de ces derniers est propre à leur mise en place et donc loin des préoccupations métier (rigidité du code patron, localisation/ non réutilisation du code …). L’externalisation en aspect est, donc, une bonne approche pour les contrôler et les rendre transversaux.

Patron Proxy

• Ce patron de développement permet à travers un objet de substitution d’accéder à un objet dit original. Très générique, il se décline en pratique en deux types principaux:
• Proxy d’accès (protection/perf) : vérifie les accès à un objet (instanciation coûteuse, chargement coûteux en ressource, gestion de droit/profile, …) avant d’en fournir un substitut.
• Proxy distant ou distribué : accès à un objet distant via un représentant local (espaces d’adressage différents) en cachant toute la complexité de la communication réseau.

Dans l’exemple qui suit, nous considérons un proxy de gestion de droit d’accès :

[/caption]

Cet exemple met en évidence quelques inconvénients du patron proxy. Nous noterons que :

• Le développement de la classe intermédiaire (proxy) peut rapidement devenir lourd car elle doit être synchronisée avec chaque modification de la classe originale.
• Dans notre classe de test (classe client), rien ne nous empêche de faire appel directement à l’objet original (instanciation directe par un collaborateur ne connaissant pas l’existence du proxy). Dès lors, si nous souhaitons imposer le passage par le proxy ceci met en évidence l’absence de mécanisme intrinsèque de contrôle.

La POA apporte une solution concrète à ces deux inconvénients qui de notre point de vue sont majeurs. L’exemple ci-dessous montre la puissance que confère la POA au design pattern.

Commençons par décrire un aspect abstrait que nous pouvons spécialiser selon les besoins. L’objectif est d’avoir un aspect générique et réutilisable. Ce dernier définit les méthodes à implanter, ainsi que le greffon réutilisable (utilisation AspectJ).

package fr.soat.aop.aspects.dp;

import fr.soat.java.busines.User;

/** Aspect de type abstrait destiner à l'héritage */
public abstract aspect AbstractProxyAspect {

protected User user;

/** Méthode abstraite : à redéfinir pour tester profile */
protected abstract boolean isAdmin();

/** Point de coupure abstrait à redéfinir par héritage */
protected abstract pointcut controlerAcces();

/** Code greffon mis en commun */
before() : controlerAcces() {
if(!isAdmin()) {// lancement d'une exception fonctionnelle
throw new RuntimeException("Accès Refusé : droits insuffisants"
+ thisJoinPoint.getSignature().getName());
}
}
}

Les aspects dérivés doivent redéfinir les méthodes abstraites déclarées.

package fr.soat.aop.aspects;

import fr.soat.aop.aspects.dp.AbstractProxyAspect;

public aspect AdminAccesProxyAspect extends AbstractProxyAspect {

/** Implémentation basique utilisée par la gestion de profile */
protected boolean isAdmin() {
return user.isAdmin();
}

/** Gestion de tous les appels aux méthodes de type mutateur */
protected pointcut controlerAcces():call (* ProfileManager.set*(..));

}

L’utilisation d’un module aspect combiné à un patron de développement permet :

• D’externaliser le code propre à l’utilisation du patron (fonctionnalité transversale). Dans notre cas, il s’agit de l’implémentation du patron proxy.
• L’utilisation du patron de façon non intrusive. Dans notre exemple, tout appel aux méthodes de la classe « ProfileManager », passera forcement par le proxy. L’utilisateur ne pourra plus instancier directement la classe concernée par la gestion d’accès. Une meilleure maîtrise du design de l’application devient possible.

Conclusion

Dans l’approche AOP, l’analyse joue un rôle très important. Il est recommandé de bien identifier les aspects transversaux pour pouvoir les modulariser et les réutiliser. Sauf cas simple, l’absence d’une bonne analyse ne conduira qu’à l’externalisation d’une partie du traitement. Au final, la dispersion du code persistera et nous n’aurions gagné ni en clarté ni en modularité.

HANNEMANN et KIRCZALES ont défini quatre critères d’évaluation d’une bonne mise en place des concepts AOP :

• Localisation : le code technique doit être centralisé dans un aspect
• Réutilisation : la définition d’un aspect doit être assez générique pour pouvoir être utilisé par plusieurs classes.
• Composition : une classe bénéficiant de l’utilisation d’un aspect, peut participer dans d’autres patrons car les aspects ne sont pas intrusifs. En cas de composition, il faudra être vigilant pour éviter d’éventuels effets de bord.
• Adaptation : le lien entre la classe et l’implémentation de l’aspect est faible. L’évolution de ce dernier peut s’effectuer sans conséquences sur la classe métier.

Si l’un ou plusieurs (hormis la composition) de ces critères ne sont pas remplis, la mise en place de la POA est non recommandée.

Pour finir, il faut savoir que le raffinement par POA ne s’applique pas à tous les patrons de développement. L’étude de HANNEMANN ET KIRCZALES conclut que les patrons usine, usine abstraite, façade et intercepteur (pour ne citer que les plus utilisés) ne tirent aucun profit de la POA.

V.    Conclusion

Il s’agit donc de concepts et ensembles de techniques dont le but, quand ils sont bien utilisés, est de permettre:

–          Un Gain de productivité : en identifiant et séparant les logiques métiers, des différents aspects applicatifs et techniques. Les tâches de développement peuvent être quantifiées et parallélisées. Couplés à une méthodologie de travail comme XP qui permet un mixage des compétences, les membres d’une équipe pourront intervenir aussi bien sur les fonctionnalités métier que sur les préoccupations transversales.

–          Une Réutilisabilité & flexibilité : Les modules n’interagissent avec le système qu’à travers des aspects. Ils peuvent être spécialisés ou changés sans risque pour le système. Les nouvelles fonctionnalités peuvent être elles-mêmes implantées sous forme de nouveaux modules.

Une Facilité de Maintenance : la séparation des préoccupations (Séparation of concernes) conduit à la spécialisation du code. La lisibilité (qualité) s’en trouve améliorée.