Programmation orientée aspect vs programmation orientée object

Comme la plupart des développeurs ici et dans le monde entier, je développe des systèmes logiciels utilisant des techniques de programmation orientée object (OOP) depuis de nombreuses années. Donc, quand je lis que la programmation orientée aspect (AOP) résout un grand nombre des problèmes que la POO traditionnelle ne résout pas complètement ou directement, je pense que c’est vrai?

J’ai lu beaucoup d’informations en essayant d’apprendre les clés de ce paradigme AOP et je suis au même endroit. Je voulais donc mieux comprendre ses avantages dans le développement d’applications réelles.

Est-ce que quelqu’un a la réponse?

    Pourquoi “vs”? Ce n’est pas “vs”. Vous pouvez utiliser la programmation orientée aspect en combinaison avec la functional programming, mais aussi en combinaison avec la programmation orientée object. Ce n’est pas “vs”, c’est “Programmation Orientée Aspect avec Programmation Orientée Objet”.

    Pour moi, l’AOP est une sorte de “méta-programmation”. Tout ce que fait AOP pourrait aussi être fait sans cela en ajoutant simplement du code. AOP vous enregistre simplement en écrivant ce code.

    Wikipedia a l’un des meilleurs exemples pour cette méta-programmation. Supposons que vous ayez une classe graphique avec de nombreuses méthodes “set … ()”. Après chaque méthode définie, les données des graphiques ont été modifiées, les graphiques ont donc été modifiés et les graphiques doivent donc être mis à jour à l’écran. Supposons de repeindre les graphiques que vous devez appeler “Display.update ()”. L’approche classique consiste à résoudre ce problème en ajoutant du code . A la fin de chaque méthode définie, vous écrivez

    void set...(...) { : : Display.update(); } 

    Si vous avez 3 méthodes, ce n’est pas un problème. Si vous avez 200 (hypothétique), cela devient vraiment pénible d’append ceci partout. Aussi, chaque fois que vous ajoutez une nouvelle méthode set, vous devez vous assurer de ne pas oublier de l’append à la fin, sinon vous venez de créer un bug.

    AOP résout ce problème sans append des tonnes de code, au lieu de cela, vous ajoutez un aspect:

     after() : set() { Display.update(); } 

    Et c’est tout! Au lieu d’écrire le code de mise à jour vous-même, il vous suffit de dire au système qu’après avoir atteint un pointcut set (), il doit exécuter ce code et exécuter ce code. Pas besoin de mettre à jour 200 méthodes, pas besoin de vous assurer de ne pas oublier d’append ce code sur une nouvelle méthode set. De plus, vous avez juste besoin d’un pointcut:

     pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*); 

    Qu’est-ce que ça veut dire? Cela signifie que si une méthode s’appelle “set *” (* signifie que n’importe quel nom peut suivre après set), indépendamment de ce que la méthode retourne (premier astérisque) ou de ses parameters (troisième astérisque) et c’est une méthode de MyGraphicsClass class fait partie du package “com.company. *”, alors il s’agit d’un setcut (). Et notre premier code dit ” après avoir exécuté une méthode qui est un sharepoint coupe défini, lancez le code suivant”.

    Voyez comment AOP résout élégamment le problème ici? En fait, tout ce qui est décrit ici peut être fait au moment de la compilation. Un préprocesseur AOP peut simplement modifier votre source (par exemple, en ajoutant Display.update () à la fin de chaque méthode set-pointcut) avant même de comstackr la classe elle-même.

    Cependant, cet exemple montre également l’un des grands inconvénients de l’AOP. AOP est en train de faire quelque chose que de nombreux programmeurs considèrent comme un ” anti-pattern “. Le modèle exact est appelé ” Action à distance “.

    L’action à distance est un anti-pattern (une erreur commune reconnue) dans lequel le comportement dans une partie d’un programme varie énormément selon qu’il est difficile ou impossible d’identifier des opérations dans une autre partie du programme.

    En tant que débutant dans un projet, je pourrais simplement lire le code de n’importe quelle méthode d’ensemble et le considérer comme cassé, car il semble ne pas mettre à jour l’affichage. Je ne vois pas simplement en regardant le code d’une méthode set, après son exécution, un autre code sera “magiquement” exécuté pour mettre à jour l’affichage. Je considère cela comme un sérieux inconvénient! En apportant des modifications à une méthode, des bogues étranges peuvent être introduits. Comprendre davantage le code du code où certaines choses semblent fonctionner correctement, mais ne sont pas évidentes (comme je l’ai dit, elles fonctionnent comme par magie …), est vraiment difficile.

    Mettre à jour

    Juste pour clarifier cela: Certaines personnes peuvent avoir l’impression que je dis que l’AOP est quelque chose de mauvais et qu’il ne faut pas l’utiliser. Ce n’est pas ce que je dis! AOP est en fait une excellente fonctionnalité. Je dis juste “Utilisez-le soigneusement”. L’AOP ne posera que des problèmes si vous mélangez du code normal et de l’AOP pour le même aspect . Dans l’exemple ci-dessus, nous avons l’aspect de mettre à jour les valeurs d’un object graphique et de peindre l’object mis à jour. C’est en fait un seul aspect. Coder la moitié comme un code normal et l’autre moitié comme un aspect est ce qui ajoute le problème.

    Si vous utilisez AOP pour un aspect complètement différent, par exemple pour la journalisation, vous ne rencontrerez pas le problème anti-pattern. Dans ce cas, un débutant au projet pourrait se demander “D’où viennent tous ces messages de journal? Je ne vois aucune sortie de journal dans le code”, mais ce n’est pas un problème majeur. Les modifications qu’il apporte à la logique du programme vont difficilement briser la fonction de journalisation et les modifications apscopes à la fonction de journalisation vont à peine rompre la logique du programme – ces aspects sont totalement séparés. Utiliser AOP pour la journalisation a l’avantage que votre code de programme peut se concentrer entièrement sur ce qu’il doit faire et que vous pouvez toujours avoir une journalisation sophistiquée, sans que votre code soit encombré par des centaines de messages de journal. De plus, lorsqu’un nouveau code est introduit, les messages de journal magiques apparaîtront au bon moment avec le bon contenu. Le programmeur débutant peut ne pas comprendre pourquoi il est là ou il vient, mais comme il va enregistrer la “bonne chose” au “bon moment”, il peut simplement accepter le fait qu’il est là et passer à autre chose. .

    Donc, un bon usage de AOP dans mon exemple serait de toujours enregistrer si une valeur a été mise à jour via une méthode définie. Cela ne créera pas d’anti-modèle et sera rarement la cause d’un problème.

    On pourrait dire que si vous pouvez facilement abuser de l’AOP pour créer autant de problèmes, c’est une mauvaise idée de tout utiliser. Cependant, quelle technologie ne peut pas être abusée? Vous pouvez abuser de l’encapsulation de données, vous pouvez abuser de l’inheritance. Presque toutes les technologies de programmation utiles peuvent être utilisées abusivement. Considérons un langage de programmation tellement limité qu’il ne contient que des fonctionnalités qui ne peuvent pas être abusées; un langage où les fonctionnalités ne peuvent être utilisées qu’à l’origine, elles étaient destinées à être utilisées. Un tel langage serait si limité qu’il serait discutable s’il peut même être utilisé pour une programmation du monde réel.

    La POO et l’AOP ne s’excluent pas mutuellement. AOP peut être un bon ajout à la POO. AOP est particulièrement pratique pour append du code standard tel que la journalisation, le suivi des performances, etc. aux méthodes sans obstruer le code de méthode avec ce code standard.

    La programmation orientée aspect permet de mettre en œuvre des préoccupations transversales telles que la journalisation, la sécurité. Ces aspects transversaux sont des éléments logiques qui doivent être appliqués à de nombreux endroits, mais qui n’ont en fait rien à voir avec la logique métier.

    Vous ne devriez pas voir AOP comme un remplacement de la POO, mais plutôt comme un complément intéressant, qui rend votre code plus propre, plus souple et axé sur la logique métier. Ainsi, en appliquant l’AOP, vous aurez 2 avantages majeurs:

    1. La logique de chaque problème se trouve maintenant au même endroit, au lieu d’être dispersée sur toute la base de code.

    2. les classes sont plus propres puisqu’elles ne contiennent que du code pour leur principale préoccupation (ou fonctionnalité principale) et que les préoccupations secondaires ont été déplacées vers d’autres aspects.

    Je pense qu’il n’y a pas de réponse générale à cette question mais une chose à noter est que l’AOP ne remplace pas la POO mais ajoute certaines caractéristiques de décomposition qui traitent de la soi-disant tyrannie de la composition dominante ( 1 ).

    Cela aide certainement dans certains cas tant que vous maîsortingsez les outils et les langages à utiliser pour un projet spécifique, mais ajoute également un nouveau niveau de complexité concernant l’interaction des aspects et le besoin d’outils supplémentaires comme l’ AJDT pour comprendre votre programme

    Gregor Kiczales a déjà fait un exposé introductif intéressant sur AOP à Google Tech Talks, que je recommande de regarder: Programmation orientée aspect: recherche radicale en modularité .

    Tout d’abord, l’AOP ne remplacera pas la POO. AOP étend la POO. Les idées et les pratiques de la POO restnt pertinentes. Avoir un bon design d’object facilitera probablement son extension.

    Je pense que les idées qu’apporte AOP sont importantes. Nous devons trouver des moyens de mettre en œuvre des préoccupations transversales pour différentes classes de votre programme sans avoir à changer les classes elles-mêmes. Mais je pense que l’AOP finira par faire partie d’autres outils que nous utilisons et non d’un outil ou d’une technique distinct. Nous voyons déjà cela se produire.

    Un couple de langages dynamics comme Ruby et Python ont des constructions de langage comme les mixins qui résolvent les mêmes problèmes. Cela ressemble beaucoup à l’AOP mais est mieux intégré dans le langage.

    Spring et Castle et quelques autres infrastructures d’dependency injection ont des options pour append un comportement aux classes injectées. C’est une façon de tisser le runtime et je pense que cela a beaucoup de potentiel.

    Je ne pense pas que vous devrez apprendre un tout nouveau paradigme pour utiliser AOP. Les idées sont intéressantes mais sont lentement absorbées par les outils et les langages existants. Restez informé et essayez ces outils.

    AOP est un nouveau paradigme de programmation traitant de ce concept. Un aspect est une entité logicielle implémentant une partie non fonctionnelle spécifique de l’application.

    Je pense que cet article est un bon sharepoint départ pour la programmation orientée aspect: http://www.jaftalks.com/wp/index.php/introduction-to-aspect-oriented-programming/