Programmation Orientée Aspect - votre avis

**Alec6** · 12/10/2006, 11h31

Et oui ?

Le but reste toujours de réussir à modéliser le monde.

Qu'est ce qu'il peut bien avoir de plus abstrait que l'aspect ?

Ca rappel le livre de cordon: concevoir des machines pensantes.

On a des données et le traitement regroupé en objet (logique et pratique), l'objet étant comme un sous programme fonctionnel et un système (encapsulation). L'aspect c'est une méta-programmation permettant le controle de flux (en fin surtout le controle de l'encapsulation). Et au dessus de ca il y a quoi. En relisant Cordon, peut etre que les objets aurait du etre reclassifiés en phénomène ??

**narmataru** · 29/06/2004, 10h49

Bien sure que l'on regroupe déjà les objets par responsabilité. Les packages sont là pour ça. De la à dire qu'on peut faire de la POA simplement en faisant celà... Ca reviendrais un peu à dire que l'on peut faire de la POO avec un langage procédurale. Un peu à la manière des objets de la librairie GTK qui sont pourtant en C. Ca ressemble mais bon c'est un peu limité. On peut penser qu'une struture associé à une liste de fonctions suffit à faire un objet mais bon ce n'est très pratique pour gérer l'héritage, le polymorphisme etc...
Pour ma part, je ne pense pas que l'on puisse faire de la POA vraiment aboutie rien qu'avec un langage objet de la même manière que l'on ne peut pas faire de la POO avec un langage procédurale. On peut s'y rapporcher mais ça reste assez basique.
La POA sera vraiment intéressant lorsqu'il y aura un langage créé dès le début avec cette optique.

En bref, rien de révolutionnaire...Juste un nom sur une approche de réflexion utilisée en POO depuis longtemps.

Oui bien sure. Mais si cette réfléxion est poussé à l'extrème et intégré au sein même d'un langage ça ne peut être qu'une évolution bénéfique

(qui engendreront surement d'autres réflexions et ainsi de suite. Ca doit être comme ça qu'on avance non ?)

**Alec6** · 29/06/2004, 10h56

Il existe déjà un langage qui étend JAVA pour fournir des mot clés dédiés à la POA et ils risquent de tirer la bourre avec les framework purement JAVA dédiés à la POA

**Arwamour** · 03/07/2004, 23h44

POA se vante plus qu'elle vaut c ni révoluton ni innovation mais simple méthode technique ou moins encore "astuces"
pourtant ca s'avère trèes interessant quand on aborde de grands et de complexes projets

**Madmac** · 10/07/2004, 06h59

Après une visite du site, j'ai impression que l'on veux implanté dans ce modèle des idées qui ont été dévellopées avec le tcl (les agents)...

**Hephaistos007** · 02/11/2005, 23h22

La programmation par aspect n'est qu'un "Add-on" des langages traditionnels, objets ou non. Elle permet d'apporter une solution élégante au pattern SoC (Separation Of Concern[1]). Les bénéfices au niveau de la maintenance de votre système sont évidents.

L'aspect est tissé (par un weaver[2]) pour produire du code traditionnel. En d'autres termes, une fois la compilation effectuée, la notion d'aspect n'existe plus.

_______________
[1] Séparation des préoccupations
[2] Tisseur

**max44410** · 22/07/2006, 19h04

Bonjour,

Pour ma part, j'ai suivi des cours de programmation par contrat avec Eclipse (en université). c'est très interessant car avec cette méthode de programmation on ne peut pas faire abstraction des specifications, on les retrouves dans chaque méthodes ou fonctions. les tests unitaires découlent des conditions que l'on s'est fixées auparavant.

Pour ma part, c'est une méthode de programmation robuste avec laquelle il est plus facile de ne pas avoir de bug ou de mauvaise surprise. Bien sur la partie analyse des post-conditions, pre-conditions, des conditions initiales, ... sont très importantes, ce sont elles qui nous permettes d'etre plus sur du fonctionnent de notre application. De plus cela permet de se rapprocher un plus du monde réel... je veux dire par là que les conditions de validations correspondent généralement au problème réel. D'ailleur outre la programmation cette méthode peut être appliquée dans tout autre projet.

Pour ma part c'est l'avenir de la programmation, ce qu'il manque ... c'est un langage spécifique, car nous nous avons travailler avec JAVA et une bibliothèque qui permet de mettre en place cette méthode de programmation. Pour finir je crois me rappeler que cette méthode n'est pas si récente que cela, je me rapel que des intervenants était venus lorsque j'étais en BTS (3-4 ans) nous présenter cela.

**Hephaistos007** · 22/07/2006, 19h23

Saches que le langage Eiffel supporte la programmation par contrat. Et quel rapport avec la programmation par aspect ?

**Captain_JS** · 27/07/2006, 17h59

En fait ce que dit est expliqué dans le lien http://www-igm.univ-mlv.fr ..., c'est du service. Certaines personnes ont appelé Aspect ce que d'autres appelent maintenant Service.

Le fait que "chaque unité implémentée (Aspect) reste inconsciente du fait que les autres unités peuvent l’instancier en tant qu’aspect" exprime tout ce qu'est un service.

Maintenant ma question est : pourquoi mettre cette "logique" derrière un mot comme Aspect (qui moi ne m'évoque rien

), alors (à mon avis) que si on parle de service, ça parle à tout le monde.

Personnelement ça me fait marrer de voir qu'on commence seulement à en parler (je dis ça parce que ce post est alimenté) alors que des services sont utilisés depuis quelques temps déjà.

**Hephaistos007** · 27/07/2006, 20h18

Envoyé par Captain_JS

Maintenant ma question est : pourquoi mettre cette "logique" derrière un mot comme Aspect (qui moi ne m'évoque rien

), alors (à mon avis) que si on parle de service, ça parle à tout le monde.

Les services fonctionnels (métiers) conserve cette dénomination. Les services non-fonctionnels sont appelés aspects pour (a) les différencier, (b) dénoter leur rôle transversal. Par ailleurs le terme aspect convient bien. La sécurité, les transactions, la persistance ne sont que les aspects d'une architecture. D'ailleurs on peut doit pouvoir les enlever/ajouter à tout moment, cela ne remet pas en cause la logique métier.
Tu as la réponse à ta question.

Envoyé par Captain_JS

Personnelement ça me fait marrer de voir qu'on commence seulement à en parler (je dis ça parce que ce post est alimenté) alors que des services sont utilisés depuis quelques temps déjà.

Le retard est - malheureusement - celui qui existe toujours entre le monde de la recherche et celui de l'entreprise. Les chefs de projet n'ont qu'à s'intéresser un peu plus à ce qui se fait chez les chercheurs. La "veille technologique" est sur tous leurs CV mais peu en font réellement.

**simonlt** · 04/06/2009, 10h29

Pour ma part, j'ai testé AspectJ sous Eclipse dans le but dans le contexte de recherche d'amélioration de performance. En gros, je l'ai utilisé pour injecter en début et fin de méthode du code permettant de calculer le temps d'exécution des méthodes et ainsi pister les endroits où je perdais du temps de traitement. Ce fut bien avantageux.

Cependant, j'ai galérer pour l'intégrer dans Eclipse version Ganymède.

Cette façon de travailler deviendrait très intéressant pour éviter du code d'initialisation répétitif tel l'initialisation des connecteurs sur une base de données à titre d'exemple.

**Killing Joke** · 04/06/2009, 12h37

De ce que j'ai vu, même si çà a l'air séduisant, je ne suis pas trop fan.

En effet sur le papier et sur un petit projet c'est pas mal.
Par contre çà devient vite difficile à maintenir et surtout à débugguer, parce que tu mélanges du code classique (ex. en Java) avec des comportements qui proviennent de ce qui a été paramétré via AOP ... Oui, paramétré, puisque çà se fait bien sûr dans de vulgaires fichiers de configuration où la moindre erreur sera bien difficile à déceler, surtout dès lors que les gens qui ont mis en place un comportement quelconque ont eu la bonne (c'est ironique) idée de mettre des regexp partout pour savoir quelles méthodes répondent à quel comportement ... Du coup difficile rien qu'en lisant le fichier de configuration de savoir ce qui va matcher ou non, bref, difficile de retrouver la "prédictabilité" du code : on ne se rend compte de ce qui se passe qu'à l'exécution, sans parler du fait que tout ce qui est paramétré par AOP est assez décorélé d'un outil d'Eclipse en matière de fonctions de recherches ou d'analyse.

Bref séduisant sur le principe, mais difficile à mettre en place, à maintenir, à débugger. Donc bof (de ce que j'en ai vu jusqu'ici).

**JeitEmgie** · 04/06/2009, 13h04

Envoyé par Killing Joke

De ce que j'ai vu, même si çà a l'air séduisant, je ne suis pas trop fan.

En effet sur le papier et sur un petit projet c'est pas mal.
Par contre çà devient vite difficile à maintenir et surtout à débugguer, parce que tu mélanges du code classique (ex. en Java) avec des comportements qui proviennent de ce qui a été paramétré via AOP ... Oui, paramétré, puisque çà se fait bien sûr dans de vulgaires fichiers de configuration où la moindre erreur sera bien difficile à déceler, surtout dès lors que les gens qui ont mis en place un comportement quelconque ont eu la bonne (c'est ironique) idée de mettre des regexp partout pour savoir quelles méthodes répondent à quel comportement ... Du coup difficile rien qu'en lisant le fichier de configuration de savoir ce qui va matcher ou non, bref, difficile de retrouver la "prédictabilité" du code : on ne se rend compte de ce qui se passe qu'à l'exécution, sans parler du fait que tout ce qui est paramétré par AOP est assez décorélé d'un outil d'Eclipse en matière de fonctions de recherches ou d'analyse.

Bref séduisant sur le principe, mais difficile à mettre en place, à maintenir, à débugger. Donc bof (de ce que j'en ai vu jusqu'ici).

plus un outil est puissant moins il tolère l'amateurisme…
ou
l'amateurisme aura des conséquences d'autant plus "tragiques" que l'outil est puissant…

pour le développeur bordelique dans sa méthodologie de travail, l'AOP n'améliorera pas la situation bien au contraire…

des regexp sur des pointcuts non limités à des packages bien précis est un exemple des choses à éviter…
et pouvoir limiter les pointcuts à des packages précis implique déjà un minimum d'organisation du code en amont…

quant aux fichiers de configuration : cela dépend de l'outil et du contexte utilisés…
un pur aspect (un source.aj) se suffit à lui-même…
un aspect dont le pointcut est lié à une annotation aura sa configuration disséminée dans le code java… à chaque utilisation de l'annotation en question…
et une configuration complexe de transactions peut, elle, nécessiter un xml séparé…

**_skip** · 04/06/2009, 13h40

Quelqu'un a déjà utilisé Spring ici?
Il y a d'excellents exemples dans ce framework de suppression de codes rébarbatifs rendus possibles par des aspects (quelqu'un a mentionné les property notifications en .Net, c'est dans cet ordre d'idée là).
En résultat on peut énormément simplifier le code, réduire les risques d'erreurs et faciliter la maintenance.

Je comprend pas pourquoi dès qu'un outil ou un concept est puissant on assiste à une levée de bouclier sous prétexte que "ça permet de faire de la m...".
Dans cette idée, on devrait tout supprimer puis bosser comme y'a 15 ans en arrière.

**michel.bosseaux** · 04/06/2009, 13h55

Je dois avouer que si j'avais déjà vu citée la "programmation orientée aspect" auparavant, je n'avais aucune idée de ce qui se cachait derrière ces mots.
Après avoir lu toute cette (très intéressante) discussion en détail, et un peu regardé PostSharp (merci à celui qui a donné le lien), je dois dire que je suis séduit. Et comme je suis actuellement en formation .NET, je compte bien tenter d'utiliser cette méthode en C# assez vite, pour approfondir les possibilités offertes.

Je dégage quand même de cette première approche un début de conviction que la POA est à manipuler avec précaution, qu'il faut avoir des objectifs précis, "limités", pour lequel la POA simplifie la réalisation du code. Bref que ça ne remplacera pas la POO, ça la complète seulement.
Et puis aussi, qu'il faut programmer proprement, parce que sinon ça peut vite devenir illisible. Mais ça, c'est un problème récurrent dans n'importe quel (type de) langage.

**vincent.mbg** · 05/06/2009, 09h20

J'ai déjà testé avec les fonctions décorées sans forcément trouver une grande utilité.

J'ai fait une bibliothèque pour faire des traces. Il parait que s'est pas un bon exemple à faire avec des décorateurs. Je compte re-tester

pour une application client serveur pour contrôler l'état des transactions au cas ou un serveur plante.

Sinon on peut s'en servir dans les classes mais, je n'ai pas encore expérimenter

**davcha** · 05/06/2009, 12h27

Il y a quelques temps, j'ai beaucoup utilisé PostSharp pour réaliser un O/RM.
De ce point de vue là, c'était assez séduisant, parce qu'en définitive, le but c'est aussi d'en écrire le moins possible.

Et dans le cas du "développement" d'un modèle de données, un domaine, on pisse véritablement du code...
A moins d'utiliser un O/RM justement, comme EF ou (n)hibernate... Enfin, à l'époque LinqToSQL n'était même pas sorti et je trouvais nhibernate particulièrement trop complexe pour ce que je souhaitais faire.

Quelque part, PostSharp était, du coup, assez sympa à utiliser. Mais en définitive, il y avait quelques petites choses qui m'ennuyaient tout de même.

Notamment, l'utilisation de postsharp induit une dépendance aux librairies de postsharp, à l'exécution... Personnellement, je trouve ça juste un peu "aberrant" ou "désagréable" disons... Parce que dans mon idée, cela devrait réécrire le code des méthodes et classes qui font l'objet d'un "tissage" sans provoquer de telles dépendances.
Enfin, là, j'avoue qu'il est aussi possible que je me prenne la tête, mais je n'aime pas avoir des dizaines de dépendances dans tous les sens.

**Davidbrcz** · 05/06/2009, 13h31

Il y a quelques temps, j'ai beaucoup utilisé PostSharp pour réaliser un O/RM.

O/MR ?

Notamment, l'utilisation de postsharp induit une dépendance aux librairies de postsharp, à l'exécution... Personnellement, je trouve ça juste un peu "aberrant" ou "désagréable" disons... Parce que dans mon idée, cela devrait réécrire le code des méthodes et classes qui font l'objet d'un "tissage" sans provoquer de telles dépendances.
Enfin, là, j'avoue qu'il est aussi possible que je me prenne la tête, mais je n'aime pas avoir des dizaines de dépendances dans tous les sens.

Je suis totalement d'accord avec vous. Je découvre la POA en C++ avec Aspect C++ et le code + les aspects sont fusionés dans des fichiers temporaires qui sont ensuite donnés à g++. Aucun surcout à l'execution, "juste" à la compilation.