Discussion :

[Davidbrcz]

Bonjour à tous.

Donc si j'essaye de résumer les réponses.
La POA est une technique verticale, non intrusive permetant d'éviter une dilapitation du code (bien qu'au final ca soit le cas, mais ca ne nous concerne pas).

Elle n'essaye pas de se substituer à la POO mais vient plutôt en renfort de celle ci.


hydraland >> bien que je connaisse pas AspectJ, je veux bien voir le code, merci.

simonlt >> Pourquoi ne pas avoir utilisé un profileur plutôt que la POA ?

Sinon, j'aurais une autre question.

Imaginons un aspect qui pour chaque fonction membre d'une classe, va tester avant et après les invariants de la classe via l'appel d'une méthode.

Est ce l'aspect qui doit contenir l'invariant et son implémention ou la classe contient la fonction fonction et l'aspect se contente de l'appeler ?

Dans le second cas, le code contient une méthode qui sans l'aspect, ne sera jamais appelée et là, justement, il me semble intrusif.

(si c'est pas clair, j'ai du code pour expliquer )

Merci.

[simonlt]

Effectivement, j'aurais pu utiliser un profiler.

Cependant, j'ai utilisé cette approche pour les raisons suivantes :
- je voulais apprendre le POA par l'exemple, ce qui s'appliquait bien à ma demande
- je ne connais pas trop les outils de profiling et les seuls que j'ai pu voir étaient très pénibles à mettre en place, soit payant ou bien ne me retournait pas tout à fait le genre d'information que je désirais
- j'ai déjà eu l'occasion de travailler avec un groupe d'architecte qui utilisait cette méthode de travail pour faire de la mesure de qualité

Mais c'est vraiment mes connaissances restent encore à ce jour restreinte au niveau des outils de profiling et de POA. Cependant, j'espère y remédier dans les prochains mois ou dans l'année.

[JeitEmgie]

Exemples d'utilisation AOP :

Injection de valeurs par IoC

Monitoring à l'exécution
- logging
- profiling

Transactions relationnelles

Sécurité
- contrôle d'accès
- encryption

Caching
exemple : BLOBs d'une DB mis en cache disque avec possibilité de filtering au vol (ex. : watermaking d'images en fonction de l'utilisateur ou autres paramètres d'exécution…)

Code politics enforcement (Ajout d'erreurs ou de warnings lors de la compilation)

Patching
- légitime : correction de bugs dans code dont on n'a pas les sources
- illégitime : question d'imagination…

Worm hole
communiquer un contexte d'un point haut d'un l'arbre des appels à un point bas sans devoir rajouter des paramètres le long de la chaîne d'appels

Debugging
Interception fine d'exceptions dans des cas de reproductibilité rare (très puissant en combinaison avec la technique du worm hole)

Mocking

Fallbacking

Triggering

… à l'infini…

[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).

[JeitEmgie]

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]

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]

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.

[Romain Verdier]

Dans le cadre des rencontres ALT.NET Parisiennes, une présentation sur l'AOP sera donnée le mercredi 17 Juin. Peut-être que cela intéressera certains, en tout cas, vous êtes invités. Ca sera orienté .NET, et on parlera entre autres des outils incontournables cités ici, comme PostSharp, DynamicProxy, Spring.NET, Linfu, PIAB, etc.

Ca se passera donc à Paris aux alentours de 19h30, et c'est gratuit. Pour plus d'infos et les inscriptions, ça se passe ici :

ALT.NET en France : Présentation AOP à Paris le 17 juin

Site ALT.NET France

[vincent.mbg]

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]

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]

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.

[davcha]

O/RM : object/relational mapping.

[matoze]

Pour avoir utilisé pas mal spring avec .net voici les grands points que je pourrais évoquer :
Les avantages :

• Un découpage par couche aisé, découplage (dependency injection)
• Une facilité d'intégration de module externe (et module pré intégré dans spring comme nhiberate, nunit, quartz etc...)
• Un pouvoir d'abstraction fort
• Possibilité de points de coupe (tissage)
• Mécanismes transactionnels etc...
• Un outil puissant pour les développeurs qui connaisse bien ce framework
• Beaucoup d'autres choses

Les inconvénients :

• Beaucoup de configuration xml (sur des gros projets)
• Difficulté de compréhension au début
• Effet de bord : Multiplication des singleton, abandon du paradigme objet, classe métiers trop longue, récupération de référence par cache etc...
• Interface presque obligatoire pour chaque classe
• Masquage de références, exceptions par le tissage

Je ne sait pas si cela concerne les autres frameworks qui sont basé sur l'aspect.

Il est intéressant d'utiliser spring avec des équipes de développeurs confirmés aimant apprendre. Avec une architecture qui ne repose pas uniquement sur l'outil et n'utilisant que les besoins propre au projet (en effet on à souvent envie d'explorer toute les possibilités offertes).
Garder en tête les paradigmes de l'objet, l'aspect, possibilités d'un framework et tirer les bénéfices de ces concepts sans complexifier le code.

[Tommy31]

[*]Beaucoup de configuration xml (sur des gros projets)

Pas si tu utilise les annotations, auquel cas la déclaration des beans est inutile (ce qui allège très grandement la configuration).

[*]Effet de bord : Multiplication des singleton,

Pas du tout, bien au contraire, tu as une gestion fine du cycle de vie des bean gérés par spring. Il offre d'ailleurs des mécanismes très simples pour mettre en place des factories.

abandon du paradigme objet

Tu rigoles j'espère ?

classe métiers trop longue

Quel rapport avec spring ou les aspects ?

récupération de référence par cache etc...

?

[*]Interface presque obligatoire pour chaque classe

Pas du tout, le proxing d'objet ciblé par un aspect peut se faire par cglib, auquel cas il n'y a aucune nécessité d'implémenter une interface.
L'injection de dépendance non plus, mais souhaitable pour la substitution.

Masquage de références, exceptions par le tissage

Ca veut dire quoi ?

[Tommy31]

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.

Exactement. La POO, n'est qu'une dimension supplémentaire qui permet de capturer atomiquement certains élément conceptuels (concerns) qui se seraient retrouvés dispersés dans les autres dimensions (fonction, procédure, classe, pattern... ).

Et la sélection de la bonne dimension doit se faire judicieusement pour en tirer tous les bénéfices. Les domaines pour lesquels l'OA s'illustre bien ont été énumérés par JeitEmgie. On peut y rajouter l'implémentation des design patterns.

Voir la notion d'hyperespace.

[oLie]

C'est peut être une bêtise que je vais dire, ou bien cela a peut être déjà été dit mais est ce que cette POA n'est pas une généralisation de l'utilisation de décorateurs tout simplement ?

Quelle est la véritable valeur ajoutée de cette pratique comparée a celles existantes (UML 2 et application de DP entre autre) ?

J'ai l'impression que le degré d'abstraction est tellement élevée que même les explications me paraissent abstraites !!

[_skip]

Pour moi, le grand intérêt de la POA, et indirectement de Spring, c'est la capacité de profiter de fonctionnalité sans le code intrusif qui va avec.

Un excellent exemple se trouve dans la gestion des transactions. Si vous voulez créer manuellement des méthodes capables d'ouvrir une transaction ou alors en utiliser une existante, l'annuler si besoin, encapsuler l'exception... Ca vous fera facilement 10-15 lignes de code juste pour la gestion d'erreur! 10-15 lignes dont vous serez peut etre bien forcé de copier-coller la majeure partie dans vos 200 méthodes.

C'est que du bonheur pour ce genre de chose de pouvoir simplement utiliser une annotation, le code devient immédiatement plus concis et facile à lire car libéré des try-catch-if multi-imbriqués... Et c'est très maintenable!

Idem pour la sécurité, pas de répétition abusive de test d'autorisation, de gestion du rejet etc....

En fait c'est peut être le genre de chose dont on n'a toujours l'impression que c'est trop compliqué, trop *magique* puis quand on s'y intéresse de près on se rend compte que finalement ce n'est pas anarchique du tout quand c'est maîtrisé (comme tout).
Et surtout, depuis que j'ai utilisé spring et ses transactions pour la DAO d'un projet, je trouve impensable de gérer ceci manuellement.

[oLie]

Ca vous fera facilement 10-15 lignes de code juste pour la gestion d'erreur! 10-15 lignes dont vous serez peut etre bien forcé de copier-coller la majeure partie dans vos 200 méthodes

Est-ce que dans ce cas particulier tu ne pourrais pas appliquer le 'template method' qui est déjà prévu pour ce genre de cas ?

[_skip]

Est-ce que dans ce cas particulier tu ne pourrais pas appliquer le 'template method' qui est déjà prévu pour ce genre de cas ?

Pas vraiment je trouve parce que...

- Les paramètres des méthodes style DAO sont toujours différents (quels seraient ceux de la méthode template???).
- Tu devrais créer presque une classe par action (dans laquelle tu redéfinis la partie *centrale* de la méthode template), ce qui fait rapidement trop.

Puis il resterait la propagation ou non des transactions DB.
Si par exemple tu veux créer une transaction métier (ajouterClient) qui peut être utilisée aussi bien toute seule qu'encapsulée dans une transaction plus importante (ajouterClientEtCreerCommande). La tout de suite il te faut

1) une méthode ajouterClient capable de créer la connexion et ouvrir une transaction DB puis la commiter.
2) un overload d'ajouterClient qui accepte une connexion ouverte en param pour pouvoir faire partie de la transaction DB en cours, sans commiter celle-ci.

Bref ce sont de petits problèmes qui deviennent vite lourds, même sur des petits projets.

[oLie]

Pas vraiment je trouve parce que...

- Les paramètres des méthodes style DAO sont toujours différents (quels seraient ceux de la méthode template???).
- Tu devrais créer presque une classe par action (dans laquelle tu redéfinis la partie *centrale* de la méthode template), ce qui fait rapidement trop.

Puis il resterait la propagation ou non des transactions DB.
Si par exemple tu veux créer une transaction métier (ajouterClient) qui peut être utilisée aussi bien toute seule qu'encapsulée dans une transaction plus importante (ajouterClientEtCreerCommande). La tout de suite il te faut

1) une méthode ajouterClient capable de créer la connexion et ouvrir une transaction DB puis la commiter.
2) un overload d'ajouterClient qui accepte une connexion ouverte en param pour pouvoir faire partie de la transaction DB en cours, sans commiter celle-ci.

Bref ce sont de petits problèmes qui deviennent vite lourds, même sur des petits projets.

J'aurais tendance a penser qu'une bonne réflexion de conception pourrais résoudre ces problèmes, c'est pourquoi je reste dubitatif sur l'efficacité d'un tel paradigme.
J'ai l'impression qu'on ne constate son efficacité que sur un aspect "maintenance" de code à partir d'un code existant, mais je vois pas bien comment l'utiliser en partant de zéro sans interférer avec des 'modèles' existants...a moins de n'avoir toujours pas compris.

Peut-être que lorsque j'aurais bien compris ses fonctionnalités je l'adopterais tout de suite, aurais-tu des documents assez clair sans être trop proche d'un quelconque langage qui serait capable d'expliquer "ce que c'est" ?