Est-ce que le concept d'agent que l'on trouve dans certains langages est proche ?
A priori, non... Si on parle d'agents logiciels, c'est encore autre chose ... bon après ça dépends du sens que donnent ces lanages au terme d'agent :-) (quels langages ?)
Pour revenir sur l'AOP... Le but des méthodes de programmation comme la programmation procédurale (séparer et factoriser du code dans des procédures) ou la programmation orientée objet est d'améliorer la structuration des programmes, de façon à simplifier leur programmation, leur maintenance, et accessoirement de pouvoir factoriser du code quand c'est possible.
La programmation par aspects propose une façon de factoriser du code qui ne pouvait pas l'être auparavant (du moins, plus difficilement), car faisant *partie* d'un code déja structuré. Reprenons l'exemple des traces. Tu as un programme qui au cours de son exécution, affiche différentes traces (printf) te permettant de savoir ou en est son fonctionnement.
Tu n'as pas de moyen simple d'isoler cet "aspect" de ton programme dans une procédure ou un objet; que l'affichage soit fait par un printf ou une autre fonction ou objet, de toute façon tu auras du aller mettre toutes les traces "à la main" dans ton source. Problème donc, si tu veux modifier ça, il faut le faire à la main. Si tu veux modifier tes printf pour envoyer ça sur le réseau dans une socket, tu est obligé de tout modifier à la main. Eventuellement tu peux encapsuler ça dans une fonction chargée de "tracer" (envoyer à l'écran, envoyer sur le réseau, etc.), mais le problème est le même: tous tes appels sont disséminés partout.
Avec AspectJ par exemple, il te suffit de définir un aspect "Trace" qui fera ce qui t'intéresse (par exemple, un printf), et ensuite tu indique à quel endroit de ton code cet aspect Trace va s'intégrer (par exemple, dans toutes les méthodes de la classe "Toto", avant et après chaque appel) !
Avantage : l'aspect "Trace" de ton programme est défini à un seul endroit, tu peux alors très simplement décider d'étendre son domaine d'application comme tu le souhaites (voir le virer).
En fait grâce à la programmation par aspects, tu isoles des parties de code qui ne pouvaient pas l'être simplement avant, ou qui pouvaient l'être mais qui nécessitaient un travail de conception préalable : encapsulation, utilisation de design patterns, etc. Hors on ne peut *pas* avoir pensé à toutes les possibilitées d'évolution et tout définir, le logiciel deviendrait bien trop énorme et difficile à programmer.
L'autre gros intérêt de la programmation par aspect, c'est la possibilité de "composer" des morceaux de code, par exemple une équipe travaille sur un logiciel, et une deuxième équipe travaille sur un autre "aspect" qui sera ensuite composé pour former le logiciel final.
Le langage Objective-C permets quelque chose d'un peu similaire, avec l'utilisation des categories (possibilité de rajouter des méthodes à une classe au runtime, sans même avoir besoin du code source de la classe), de la méthode poseAs: (qui permets d'insérer une classe dans un arbre d'héritage), ou l'usage des bundles (possibilité de charger à la volée du code).
L'AOP va en général plus loin (cf AspectJ et ses définitions de "pointcuts" très élaborées), mais une chose est sure, c'est que cette approche permets une conception plutôt propre et surtout, évolutive, d'un programme.
[^] # Re: Conférence sur la programmation orientée aspect et JAC, à Toulouse.
Posté par Nicolas Roard . En réponse à la dépêche Conférence sur la programmation orientée aspect et JAC, à Toulouse.. Évalué à 2.
A priori, non... Si on parle d'agents logiciels, c'est encore autre chose ... bon après ça dépends du sens que donnent ces lanages au terme d'agent :-) (quels langages ?)
Pour revenir sur l'AOP... Le but des méthodes de programmation comme la programmation procédurale (séparer et factoriser du code dans des procédures) ou la programmation orientée objet est d'améliorer la structuration des programmes, de façon à simplifier leur programmation, leur maintenance, et accessoirement de pouvoir factoriser du code quand c'est possible.
La programmation par aspects propose une façon de factoriser du code qui ne pouvait pas l'être auparavant (du moins, plus difficilement), car faisant *partie* d'un code déja structuré. Reprenons l'exemple des traces. Tu as un programme qui au cours de son exécution, affiche différentes traces (printf) te permettant de savoir ou en est son fonctionnement.
Tu n'as pas de moyen simple d'isoler cet "aspect" de ton programme dans une procédure ou un objet; que l'affichage soit fait par un printf ou une autre fonction ou objet, de toute façon tu auras du aller mettre toutes les traces "à la main" dans ton source. Problème donc, si tu veux modifier ça, il faut le faire à la main. Si tu veux modifier tes printf pour envoyer ça sur le réseau dans une socket, tu est obligé de tout modifier à la main. Eventuellement tu peux encapsuler ça dans une fonction chargée de "tracer" (envoyer à l'écran, envoyer sur le réseau, etc.), mais le problème est le même: tous tes appels sont disséminés partout.
Avec AspectJ par exemple, il te suffit de définir un aspect "Trace" qui fera ce qui t'intéresse (par exemple, un printf), et ensuite tu indique à quel endroit de ton code cet aspect Trace va s'intégrer (par exemple, dans toutes les méthodes de la classe "Toto", avant et après chaque appel) !
Avantage : l'aspect "Trace" de ton programme est défini à un seul endroit, tu peux alors très simplement décider d'étendre son domaine d'application comme tu le souhaites (voir le virer).
En fait grâce à la programmation par aspects, tu isoles des parties de code qui ne pouvaient pas l'être simplement avant, ou qui pouvaient l'être mais qui nécessitaient un travail de conception préalable : encapsulation, utilisation de design patterns, etc. Hors on ne peut *pas* avoir pensé à toutes les possibilitées d'évolution et tout définir, le logiciel deviendrait bien trop énorme et difficile à programmer.
L'autre gros intérêt de la programmation par aspect, c'est la possibilité de "composer" des morceaux de code, par exemple une équipe travaille sur un logiciel, et une deuxième équipe travaille sur un autre "aspect" qui sera ensuite composé pour former le logiciel final.
Le langage Objective-C permets quelque chose d'un peu similaire, avec l'utilisation des categories (possibilité de rajouter des méthodes à une classe au runtime, sans même avoir besoin du code source de la classe), de la méthode poseAs: (qui permets d'insérer une classe dans un arbre d'héritage), ou l'usage des bundles (possibilité de charger à la volée du code).
L'AOP va en général plus loin (cf AspectJ et ses définitions de "pointcuts" très élaborées), mais une chose est sure, c'est que cette approche permets une conception plutôt propre et surtout, évolutive, d'un programme.