approches Aspect
3.3 Application aux autres patrons du GoF
Les trois langages orientés aspect essayent de mettre le code de patrons de conception dans des éléments distincts et parfois réutilisables, ce qui libère les classes de l’application des rôles imposés par les patrons.
Dans cette sous section, nous allons décrire les solutions aspect suivant les six groupes proposés par Hannemann et Kiczales [Hannemann, 2002] :
3.3.1 Groupe 1(Observateur / Médiateur /Chaine de responsabilités / Composite / Commande)
Tous les patrons de conception de ce groupe introduisent des rôles supplémentaires sur différentes classes de l’application.
64
Avec AspectJ et comme nous l’avons vu dans l’exemple illustratif ces rôles sont réalisés avec des interfaces vides (protégées) dans l’aspect abstrait, qui contient aussi toutes les méthodes générales nécessaires à la réalisation de ce patron. Le raffinement de ces méthodes est ensuite assurer par un aspect concret afin de projeter le patron sur une application particulière. Cette logique est peut être considérée comme une bonne pratique mais dans certains cas elle n’est pas suffisante, par exemple si on prend le patron de conception observateur on trouve que l’utilisation des aspects abstraits comme un seul module réutilisable ne donne pas une meilleure conception car on doit raffiner la gestion des observateurs dans chaque aspect concret. Ce problème sera discuté dans le chapitre suivant.
JBoss AOP suit presque la même logique que celle d’AspectJ, seulement, il utilise des éléments en Java pur. L’utilisation des interfaces et des classes aspect comme le seul moyen de réutilisation gêne, en quelques sortes, les concepteurs. On peut même confondre le code de base et le code non fonctionnel dans certains cas, ce qui nécessite une lecture minutieuse du fichier XML.
CaesarJ a été créé après AspectJ, il tente donc de remédier à quelques problèmes observés dans les programmes implémentés avec AspectJ. Avec CaesarJ le programme est peut être vu comme un composant qui se base sur trois parties essentielles : une interface de collaboration qui définit des méthodes générales indépendantes de toute application particulière, une implémentation qui raffine une partie de l’interface de collaboration et qui peut être considérée à son tour comme générale (i.e. comme la partie de gestion et de sauvegarde des observateurs dans le patron de conception Observateur). La dernière partie est le Binding qui relie l’interface de collaboration à une application particulière en utilisant une des présentations offertes par la partie implémentation.
La séparation du code du patron en trois niveaux a l’avantage de minimiser la répétition des codes dans les différents modules concrets de l’application.
3.3.2 Groupe 2 (Singleton/ Prototype/ Mémento/ Itérateur /Poids-mouche)
Tous les patrons de conception de ce groupe offrent aux clients des méthodes de fabrication afin de créer des instances suivant des arguments donnés, comme la création du clone dans le patron de conception Prototype, ou encore la gestion d’une seule instance dans le patron de conception Singleton.
Dans la solution AspectJ, ces patrons (voir Mémento) ont permis de produire des aspects abstraits contenant les méthodes de fabrication ou d’ajouter cette méthode sur les classes participantes à travers le mécanisme d’introduction.
Dans JBoss AOP les méthodes Fabrication sont réalisées avec des classes MixIn, les classes de bases sont par la suite ajoutées durant leur création à ces classes, ce qui leur permet de bénéficier de ces nouvelles méthodes
CaesarJ contrairement aux patrons de conception du premier groupe ou les solutions CaesarJ génèrent des parties implémentation pour les patrons de conception dans ce groupe, la solution CaesarJ peut ne pas avoir une partie réutilisable pour certain cas d’application. C’est le cas de l’exemple de la solution CaesarJ pour le patron de conception Mémento qui ne comporte pas une partie implémentation. En effet, les deux méthodes du protocole dépendent forcément d’une application spécifique.
Par contre dans le patron de conception Poids mouche la gestion du tableau est mise dans une partie implémentation ce qui donne plus d’avantage de réutilisation pour CaesarJ par rapport aux autres langages pour ce patron.
3.3.3 Groupe 3 (Adaptateur/ Décorateur/ Stratégie/ Visiteur / Proxy)
Les nouveaux concepts introduits par la programmation par aspects peuvent faire disparaître les patrons de ce groupe.
Le mécanisme d’introduction d'AspectJ montre sa puissance dans la mise en œuvre des modèles Adaptateur et de Visiteur, où avec un simple aspect concret nous avons pu réaliser ces modèles.
JBoss AOP fournit un mécanisme d'introduction moins souple que celui d’AspectJ. Il nécessite trois éléments différents: l'interface, une classe Mix-in et un fichier XML.
La mise en œuvre des trois modèles de conception Décorateur, proxy et de stratégie avec trois approches, sont basées sur des advices et des points de coupure. Dans le modèle de conception décorateur, le déploiement dynamique soutenu par JBoss AOP et CaesarJ permet de contrôler les moments où un décorateur est actif. Ce type de déploiement donne plus d'avantage à JBoss AOP et CaesarJ. 3.3.4 Groupe 4 (Fabrique abstrait/ Fabrique méthode/ Méthode patron/
Constructeur/ Pont)
Les modèles de conception de ce groupe sont structurellement similaires: L'héritage est utilisé pour distinguer des mises en œuvre différentes mais connexes [Hannemann, 2002].
L'approche suivie par AspectJ et JBoss AOP est de remplacer la classe abstraite avec une interface et l’utilisation respectivement des déclarations inter-types et les classes Mix-in pour composer les classes concrètes de l'interface. À cet égard, AspectJ et JBoss AOP offrent une forme limitée d’héritage multiple. Cependant, cette solution n'est pas la réponse directe aux objectifs des intentions déclarées pour ce groupe.
Fabrication et Fabrique abstraite sont directement prises en charge par les mécanismes CaesarJ. Mais avoir tout le code dans le composant CaesarJ peut empêcher la réutilisation des classes de base comme par exemple le modèle de conception Pont.
3.3.5 Groupe 5 (Etat / Interpréteur)
Les trois solutions proposées par AspectJ, JBoss AOP et CaesarJ pour les modèles de conception de ce groupe ne produisent pas de composants réutilisables. Ils sont essentiellement basés sur un élément concret qui modularise le code produit. Ce qui leur permet de gérer la communication entre les différentes classes participantes à l'aide de points de coupure et de consignes.
3.3.6 Groupe 6 (Façade)
Le modèle de conception de façade constitue un groupe distinct, parce que la structure de l'objet de ce modèle ne pose pas de problème pour la séparation des préoccupations.
4 Conclusion
Ce chapitre a présenté les patrons de conceptions en général et ceux du Gang of Four en particulier, il a mis l’accent sur les problèmes rencontrés lors de l’implémentation de ces patrons avec la programmation objet.
Par la suite, nous avons présenté les nouvelles solutions aspect en utilisant trois approches modernes que sont : AspectJ, JBoss AOP et CaesarJ, à travers six
66
exemples illustratifs et une discussion bien détaillée sur les 17 autres patrons de conception.
Dans le chapitre suivant, nous allons exposer notre étude comparative qui se base essentiellement sur les implémentations réalisées dans ce chapitre.