Programmation orientée aspect
L’idée de la programmation aspect de conserver un code allant droit à l’essentiel.
Une procédure de recherche de produits doit se concentrer sur la recherche, hors il est courant que ce genre de procédure soit parasité par du code de trace, de log, de cache, de sécurité, de gestion multitâche … des modules s’entrecroisent à nouveau malgré tous nos efforts de dissociation.
Au final, ce code est nécessaire, mais n’est pas l’objectif premier de la procédure et il peut pourtant occuper une grande partie du code. L’aspect fonctionnel se trouve donc également mélangé à du code plutôt technique.
La situation est bien pire lorsque ce code “parasite” est lui même source de plantage, alors qu’il n’a finalement pas grand chose à voir avec ce qui a été demandé à la procédure.
Littéralement, l’AOP ( aspect-oriented programming) permet de séparer les préoccupations transverses (cross-cutting concerns).
Un aspect est codé séparément et relié au code sur un point de jonction par le biais d’un tisseur à l’exécution ou à la compilation suivant le langage ou l’environnement.
Les compilateurs prenant en charge l’OAP produisent un code dans lequel l’aspect et le code ont été fusionnés de manière transparente à la compilation. En .NET, c’est le cas du compilateur PostSharp (payant).
A l’exécution, le principe mis en jeu est l’inversion de contrôle, au lieu d’appeler une procédure directement, le programme appelle un tisseur qui se charge d’entourer l’appel de la procédure par les aspects définis sur les points de jonction.
L’avantage est que l’aspect n’est pas ré-implémenté dans chaque procédure et peut donc faire l’objet de tests de fiabilisation poussés. Il est également facile de modifier le comportement d’un groupe de procédures sans intervenir dans le code de chacune d’elles mais sur les points de jonction.
Ce paradigme est assez peu pris en charge par les langages mais beaucoup de compléments existent pour l’utiliser.
Je leur reproche simplement de ne pas totalement respecter leurs engagements, si l'objectif est de simplifier l'écriture des fonctions, cela conduit bien souvent à une complexification de l'appel à ces fonctions (proxys, interfaces supplémentaires ...).
Difficile donc de trouver un avantage réel actuellement.
L’essentiel est de garder cette notion à l’esprit et de s’efforcer de ne pas parasiter le code.
Ce paradigme est certainement amené à se développer dans les prochaines années.
Plus de détails peuvent être trouvés sur wikipedia :
Rubriques connexes :