La programmation orientée aspect (POA, en anglais aspect-oriented programming - AOP) est un paradigme de programmation qui permet de séparer les considérations techniques (aspect en anglais) des descriptions métier dans une application. Par exemple, le principe de l'inversion de contrôle (en anglais, IOC, Inversion Of Control) peut être implémentée par cette méthode de programmation.
La programmation orientée aspect est une technologie transversale et n'est pas liée à un langage de programmation particulier mais peut être mise en œuvre aussi bien avec un langage orienté objet comme Python qu'avec un langage impératif comme le C, le seul prérequis étant l'existence d'un tisseur d'aspect pour le langage cible (cf. § Tisseurs d'aspects)
Les concepts de la programmation orientée aspect ont été formulés par Gregor Kiczales et son équipe, qui travaillait alors pour le Xerox PARC.
Les techniques actuelles de conception logicielles et de programmation amènent à découper un logiciel en modules logiciels a priori indépendants les uns des autres car gérant des aspects différents du système conçu. Certains de ces modules implémentent soit des tâches métier, soit des tâches plus applicatives comme l'authentification des utilisateurs ou encore offrant des services techniques comme la génération de trace ou le multi-threading. Ces modules représentent alors au même niveau d'abstraction, différentes considérations (différents aspects) d'une application, le plus souvent celui de la couche métier.
Exemples de modules :
Dans la pratique, les considérations techniques que sont censées implémenter les modules non seulement s'entrecroisent (par exemple la gestion des utilisateurs fait aussi appel à la génération de trace) mais aussi sont répartis dans la couche métier: c'est l'intrication ou entrecroisement des aspects techniques (crosscutting en anglais). Ainsi, une couche logicielle, initialement dédiée à gérer la logique métier applicative (par exemple un système bancaire), va se retrouver dépendante de modules gérant les aspects transactionnels, journalisation, etc., conduisant à une complexification du code, de son développement et de sa maintenance.
La programmation par aspect va permettre d'extraire les dépendances entre modules concernant des aspects techniques entrecroisés et de les gérer depuis l'extérieur de ces modules en les spécifiant dans des composants du système à développer nommés aspects ; ils sont développés à un autre niveau d'abstraction.
Ainsi, au lieu d'avoir un appel direct à un module technique depuis un module métier, ou entre deux modules techniques différents, en programmation par aspect, le code du module en cours de développement est concentré sur le but poursuivi (la logique bancaire, pour reprendre notre exemple) , tandis qu'un aspect est spécifié de façon autonome, implémentant un aspect technique particulier, par exemple la persistance ou encore la génération de trace. Un ensemble de points d'insertions ou joinpoint en anglais sont ensuite définis pour établir la liaison entre l'aspect et le code métier ou un autre aspect. Ces définitions de joinpoint sont définis dans le cadre de la POA. Selon les frameworks ou les langages d'aspects, la fusion du code technique avec le code métier est alors soit réalisée à la compilation, soit à l'exécution.
Bien sûr, si chaque aspect créé devait lui-même définir explicitement à quel point d'exécution il doit s'insérer dans le code métier ou dans un autre aspect, c’est-à-dire par exemple avec une dépendance directe vers le module métier où devra s'intercaler le code technique, on n'aurait alors fait que décaler le problème. Aussi, l'astuce particulière de la programmation par aspect consiste à utiliser un système d'expressions rationnelles pour préciser à quels points d'exécution (en anglais, joinpoint) du système l'aspect spécifié devra être activé.
Exemple/Étude de cas :
Un logiciel métier qui décrit un environnement distribué est écrit de manière classique en utilisant une décomposition fonctionnelle ou objet. Au moment du déploiement du système, on s’aperçoit que les machines physiques sur lesquelles le système va tourner ont en fait des caractéristiques hétérogènes (puissance, bande passante, etc.) qui impactent ou modifient les fonctionnalités du logiciel d’origine.
Une approche fréquente consisterait en ce cas à " patcher " le code un peu partout pour adapter le logiciel à son environnent d’exécution réel. Avec les outils d’AOP on peut facilement spécifier les changements requis SANS toucher au source du code original, dont la logique reste intacte.
Les outils de programmation par aspect sont en fait similaires aux modificateurs (before, after et around) que l’on trouve dans des langages comme LISP, auxquels on a ajouté la possibilité d’une description d’insertions déclaratives.
Un aspect permet donc de spécifier :
Le couplage entre les modules gérant des aspect techniques peut être réduit de façon très importante, en utilisant ce principe, ce qui présente de nombreux avantages :
Le tissage d'aspect qui n'est finalement que de la génération automatique de code inséré à certains points d'exécution du système développé, produit un code qui peut être difficile à analyser (parce que généré automatiquement) lors des phases de mise au point des logiciels (déboguage, test). Mais en fait cette difficulté est du même ordre que celle apportée par toute décomposition non linéaire (fonctionnelle ou objet par exemple).
Cela dit, une implémentation comme AJDT, basée sur AspectJ, offre des outils sophistiqués qui permettent de passer de façon transparente, en mode déboguage, du code d'une classe à celui d'un aspect.
La programmation orientée aspect, parce qu'elle propose un paradigme de programmation et de nouveaux concepts, a développé un jargon bien spécifique qui ne facilite pas la compréhension de ses concepts qui sont, en définitive, simples mais puissants.
Deux grandes stratégies de tissage d'aspects existent :