Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Les enjeux ou le fonctionnement? Quelques liens ont été postés sur la première page de ce topic.
Moi je le vois personnellement pas comme une nouvelle approche de conception puisque ça change pas la façon dont je réfléchis une application. Ca introduit juste certaines facilités qui permettent d'alléger mon code, les transactions étaient l'exemple principal, l'exemple posté par davcha en .Net en est aussi un.
Envoyé par oLie
Il ne faut pas voir l'AOP comme un simple ajout de comportement à un problème mal modélisé et/ou conçu.
Dans une application, il y a du code métier et du code technique (de la plomberie).
Généralement le code métier répond à des préocupations verticales tandis que le code technique répond à des préocupations horizontales (on le retrouve partout).
Aujourd'hui, grâce à l'AOP, il est très aisé de concevoir une application et puis de la développer sans avoir le mélange métier/plomberie. La plomberie pouvant étant isolée dans des aspects.
Exemples (comme déjà cité) : Transaction, Sécurité, Logging...
Nombre de très grands noms du développement Java sont aujourd'hui convaincus... pourquoi pas vous ?
Petite annotation concernant mon dernier post :
J'aurais du appeler la partie "inconvénients" -> "risques".
Je suis d'accord avec le point de vue de Tommy31 sur ce post.
J'en avais touché deux mots ici, mais mercredi dernier a eu lieu une présentation sur l'AOP en .NET, à Paris, dans le cadre des réunions ALT.NET.
Les slides sont disponibles ici si ça vous intéresse.
Globalement, j'suis d'accord, mais la, en plus, on a des outils adaptés pour mettre en place le fruit de cette réflexion, associés à un formalisme nouveau créé pour formuler des réponses à des problèmes dont l'émergence est relativement récente
Procedural programming -> functional abstraction
OOP -> object abstraction
AOP -> concern abstraction
n'essayez pas de mettre l'AOP dans le même plan que l'OOP : par définition c'est une dimension transversale…
c'est comme représenter un volume sur une feuille de papier en utilisant des techniques de projection en perspective… ce n'est pas parce que le cerveau imagine un volume en regardant le dessin que le dessin est un volume (… "ceci n'est pas une pipe" …)
il est sans doute compréhensible que d'aucuns ne percoivent pas tout le potentiel de l'AOP et tentent de la réduire à un machin en plus lié à l'OOP : la plupart des intervenants semblent être ou des développeurs ou des analystes…
or l'AOP adresse principalement des problèmes d'architecture logicielle… et en particulier les problèmes qui sont repoussés hors du champ de l'implémentation immédiate dans la phase du projet où l'on élimine les dilemnes pour des raisons opérationnelles… ("underdesign/overdesign issues") càd avant même que l'on fasse intervenir l'analyste-développeur…
donc quand l'analyste-dévoppeur est confronté à l'AOP c'est souvent dans des cas très limités qui ne laissent apparaître que le côté "trucs et astuces" du concept… d'où la propension à toujours revenir avec les mêmes exemples du logging, de la gestion des transactions… et donc de renforcer l'idée que l'AOP ne résoud pas de problèmes nouveaux… alors même que ce n'est pas son propos qui est plutôt de résoudre d'une meilleure manière certains problèmes (les "crosscuting concerns")…
et ce n'est pas parce que les outils AOP les plus connus s'utilisent avec des langages OO que l'AOP en soi nécessite un langage OO…
rien n'interdit de faire de l'AOP sur du code procédural…
d'ailleurs il ne faut pas perdre de vue que l'un des effets d'un aspect lorsqu'utilisé sur un code OO est justement de casser l'encapsulation qui est fournie par la notion de classes d'objets dans l'OOP…
il me semblait qu'on avait déjà dscuté de ce sujet, mais je n'arrive pas à remettre la main sur le thread en question..
Et je ne vais pas retaper ce que j'ai déjà tapé..
Si quelqu'un le retrouve...
En gros : l'apsect me semble extrêmement dangereux, et n'est qu'un "gizmo" de plus, principalement pour faire "faire neuf" , à mon avis...
J'ai donné mon avis sur la question sur la première page de ce topic il y a bientôt 5 ans de cela
@souviron34 :
Tu dis que l'AOP cherche à faire du neuf avec du vieux. Ma question est simple : comment gérait-on les "aspects" avant ?
aujourdhui je répondrais rapidement, tant que je n'ai pas retrouvé le bout de thread où on évoquait les pros & cons :J'ai donné mon avis sur la question sur la première page de ce topic il y a bientôt 5 ans de cela
@souviron34 :
Tu dis que l'AOP cherche à faire du neuf avec du vieux. Ma question est simple : comment gérait-on les "aspects" avant ?
en faisant une bonne analyse
Que ce soit en procédural ou en objet, l'important est le découpage ..
Et l'analyse..
Une bonne analyse, même en programmant en C, te permet , grâce aux TAD et aux void*, et aux méthodes enregistrées, tout un tas de choses..
Et bien justement ! Le constat de départ est que certaines choses ne peuvent pas être découpées et regroupées à un unique endroit. Du moins, pas avec le procédural ou l'objet. C'est la technique du tissage qui a alors permis de contourner ce problème et d'arriver à modulariser des choses "inmodularisables".
Personnellement, j'ai commencé à utiliser la programmation orientée aspect, il y a peu et mêmes si je n'utilise pas encore la totalité des possibilités de cette technologie, je suis tout à fait convaincu des avantages qu'elle apporte.
Pour définir des préoccupations transversales telles que la journalisation ou les transactions, c'est une technologie extrêmement utile et relativement simple une fois qu'on en comprend les différents concepts.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager