POA
Présentation
La programmation orientée aspect (POA), ou Aspect Oriented-Programming (AOP), est un nouveau paradigme de programmation qui a été défini par la société xerox en 1996. C'est donc une nouvelle manière de structurer, et donc de programmer, les applications.
La POA n'est pas un language de programmation, mais elle est une extension de language. Elle peut effectivement être appliqué au Java, C, C++, C# ou encore smalltalk. Il est alors possible d'appliquer la POA sur les languages de programmation procédurales ou les languages orientés object. Dans la suite de cette présentation, je me concentrais surtout sur la POA appliquée au language JAVA, donc à un language orienté object.
L'objectif principal de la POA n'est pas de remplacer les paradigmes actuellement utilisés, mais de les améliorer en essayant de résoudre certaines problématiques.
Les limites de la programmation orientée object
Le language orientée object vise à structer les objects de manière intelligente, ses principaux buts sont alors de rendre les applications plus modulables (regroupement des traitements un même ensemble de données), réutilisables et extensibles (concept d'héritage).
Les fonctionnalitées transversales
La programmation object montre ses limites dans certains cas. Prenons, par exemple, un programme gérant des commandes clientes d'objets. Si nous souhaitons supprimer un client de notre application, nous devons vérifier si une commande n'est pas en cours pour celui-ci (une commande doit être obligatoirement liée à un client). Il y a donc une contrainte d'intégrité des données. Dans notre problème, et avec la logique POO, ni l'objet commande, ni l'objet client ne peut effectuer cette opération car ce n'est pas de leur responsabilité. Il ne serait pas logique de demander à une commande de supprimer un client, ni à un client de vérifier qu'une commande est en cours (un object client ne doit pas contenir de commandes si nous voulons garder la logique objet du programme).
C'est une des problématiques que la programmation orientée aspect est capable de résoudre. Dans le cas précédement cité, nous mettrons en place la fonctionnalité de vérification d'intégrité des données avec l'aide d'un aspect.
La dispersion de code
La dispersion de code est une autre limite de la POO. L'un des exemples les plus courament utilisé pour introduire ce phénomène est la gestion des traces. Effectivement, si vous voulez afficher quelque chose à chaque appel de méthode, ou d'instanciantion d'objet, vous serez obligés d'ajouter une ligne de code avant chaqu'un de ces points du programme. Il y a donc recopie fréquente de codes dans l'ensemble du programme pour ajouter la fonctionnalitée de gestion de traces.
La programmation orientée aspect est là encore capable de résoude ce problème, en ajoutant un aspect qui capture les appels de méthodes dont le code advice serait l'affichage de la trace. Ceci est de plus très pratique, car facilement et rapidement implémentable sur un programme déjà important, mais aussi facilement supprimable.
Qu'est ce qu'un aspect ?
Pour commencer, par comparaison avec la programmation orientée objet, si une classe est une responsabilitée, nous pouvons dire qu'un aspect est une fonctionnalitée. Un aspect peut, par exemple, contenir les fonctionnalitées de traces, de sécuritées ou encore de persistance des données d'un programme. Dans cette optique, nous pouvons dire que la POA réduit la dispersion de code d'un programme comme illustré dans le schémas suivant.
Ensuite, nous pouvons dire que la programmation orienté object peut-être représentée par une programmation verticale. Cela veut dire que nous structurons les données de manière hiérarchique. C'est est d'autant plus évident lorque nous représentons un programme orienté objets en UML.
Par analogie, la programmation orientée aspect serait, quant à elle, plutôt une programmation horizontale, fonctionnant par couches. Elle va implémenter les fonctionnalitées transversales du programme.
Le shémas suivant illustre très bien la place de la programmation orientée aspect au sein de la programmation orientée ojets. Les dépendances entre objets sont extériorisées par les aspects.
Une autre force de la programmation orientée aspect est l'inversion de dépendance. Effectivement, nous pouvons ne faire dépendre que les acpects d'un service donné. De ce fait, nous réduirons les risques de mauvaises utilisation de ces services, mais aussi la dépendance de l'ensemble du programme sur celui-ci. Il sera possible de changer ce service en modifiant uniquement les aspects du programme.
Dans le schémas suivant, nous constatons bien qu'il existe une dépendance entre les services et le programme codé en orientée objet (dessin de gauche). Par contre, il n'existe aucune dépendance entre les aspects et le programme pour le programme codé en orientée aspect (droite), et la dépendance avec les services n'existe que sur les aspects. C'est se qui illustre l'inversion de dépendance.
