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 métier), 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éfinies dans le cadre de la PAO. 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 : Ajout de logs dans une application existante
Une approche fréquente consisterait en ce cas à « patcher » le code un peu partout pour rajouter des log.debug() au début et à la fin de chaque méthode. Avec les outils d'AOP on peut facilement spécifier les changements requis
SANS toucher au code source 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 :
• les