Pourquoi "vs"? Il n'est pas "contre". Vous pouvez utiliser la programmation Orientée Aspects en combinaison avec la programmation fonctionnelle, mais aussi en combinaison avec de l'Orienté Objet. Il n'est pas "contre", c'est "la Programmation Orientée Aspects avec la Programmation Orientée Objet".
Pour moi, l'AOP est une sorte de "méta-programmation". Tout ce que l'AOP ne peut être effectuée sans qu'il en ajoutant simplement plus de code. AOP seulement vous permet d'économiser de l'écriture de ce code.
Wikipedia est l'un des meilleurs exemples de cette méta-programmation. Supposons que vous disposez d'un graphique de classe avec de nombreux "ensemble... ()". Après chaque série, la méthode, les données de la carte graphique a changé, donc les graphismes changé et donc les graphismes doivent être mis à jour sur l'écran. Supposons pour redessiner la carte graphique, vous devez appeler d'Affichage".mise à jour()". L'approche classique est de résoudre ce problème en ajoutant plus de code. À la fin de chaque méthode de jeu que vous écrivez
void set...(...) {
:
:
Display.update();
}
Si vous avez 3 set-méthodes, qui n'est pas un problème. Si vous avez 200 (hypothétique), c'est vraiment douloureux pour ajouter ce partout. Aussi chaque fois que vous ajoutez une nouvelle méthode, vous devez être sûr de ne pas oublier d'ajouter ce point à la fin, sinon vous venez de créer un bug.
AOP résout ce sans ajouter 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, vous venez de dire le système qui après un set() coupe transverse (pointcut) a été atteint, il doit exécuter ce code et il va exécuter ce code. Pas de mise à jour de 200 méthodes, pas besoin de vous assurer que vous n'oubliez pas d'ajouter ce code sur une nouvelle méthode. En outre, vous avez juste besoin d'une coupe transverse (pointcut):
pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);
Qu'est-ce que cela signifie? Cela signifie que si une méthode est nommée "*" (* signifie n'importe quel nom pourrait suivre après), quelle que soit la méthode retourne (premier astérisque) ou quels paramètres il faut (troisième astérisque) et c'est une méthode de MyGraphicsClass et cette classe fait partie du package "com.de l'entreprise.*", alors c'est un set() coupe transverse (pointcut). Et notre premier code dit "après l' exécution d'une méthode est un ensemble coupe transverse (pointcut), exécutez le code suivant".
Voir comment AOP élégamment résout le problème ici? En fait tout ce qui est décrit ici peut être fait au moment de la compilation. Un AOP préprocesseur peut simplement modifier votre source (par exemple l'ajout de l'Affichage.mise à jour() à la fin de chaque set-coupe transverse (pointcut) méthode) avant même la compilation de la classe elle-même.
Cependant, cet exemple montre également l'un des grands inconvénients de l'AOP. L'AOP est en train de faire quelque chose que de nombreux programmeurs envisager un "Anti-Modèle". Le modèle exact est appelée "Action à distance".
L'Action à distance est un
anti-modèle (reconnue de la commune
d'erreur) dans laquelle le comportement dans une partie
d'un programme varie énormément basé sur
difficile, voire impossible, d'identifier
les opérations dans une autre partie de la
programme.
Comme un débutant à un projet, peut que je viens de lire le code de n'importe quel jeu-méthode et considérons qu'il est cassé, car il me semble pas de mise à jour de l'affichage. Je ne vois simplement en regardant le code d'une méthode, qu'après qu'il est exécuté, un autre code "comme par magie" être exécuté afin de mettre à jour l'affichage. Je considère cela comme un grave inconvénient! En apportant des modifications à une méthode, des bugs étranges pourrait être mis en place. Mieux comprendre le flux de code de code où certaines choses semblent fonctionner correctement, mais ne sont pas évidentes (comme je l'ai dit, ils ont juste la magie de travail... d'une certaine façon), c'est très dur.
Mise à jour
Juste pour préciser que: Certaines personnes pourraient avoir l'impression que j'ai dis l'AOP est quelque chose de mauvais et ne doit pas être utilisé. Ce n'est pas ce que je dis! L'AOP est en fait une grande fonctionnalité. Je dis juste "de l'Utiliser avec précaution". L'AOP ne fera que causer des problèmes si vous mélangez du code et de l'AOP pour le même Aspect. Dans l'exemple ci-dessus, nous avons l'Aspect de la mise à jour de la valeur d'un objet graphique et de la peinture de l'objet mis à jour. C'est en fait un aspect unique. Le codage de la moitié de cela comme normal de code et l'autre moitié en tant qu'aspect est ce qui ajoute au problème.
Si vous utilisez l'AOP pour un aspect entièrement différent, par exemple pour l'enregistrement, vous n'aurez pas de l'anti-modèle de problème. Dans ce cas, un débutant pour le projet pourrait se demander "Où vont tous ces messages de journal viennent de? Je ne vois pas la sortie du journal dans le code", mais ce n'est pas un énorme problème. Les modifications qu'il apporte à la logique du programme de la peine de briser le journal d'installation et les modifications apportées à la fonction de journalisation sera à peine briser son programme à la logique de ces aspects sont totalement séparées. À l'aide de l'AOP pour l'exploitation forestière, l'avantage est que le code de votre programme peut entièrement se concentrer sur faire tout ce qu'il doit faire et vous pouvez avoir sophistiquées de journalisation, sans avoir votre code d'être encombré par des centaines de messages de journal de partout. Aussi, quand un nouveau code est introduit, comme par magie, journal des messages apparaissent au bon moment avec le bon contenu. Le débutant programmeur peut pas comprendre pourquoi ils sont là, ni d'où ils viennent, mais depuis ils vont se connecter "la bonne chose" au "bon moment", il peut tout simplement heureux d'accepter le fait qu'ils sont là et passer à autre chose.
Donc, une bonne utilisation de l'AOP dans mon exemple serait de toujours vous connecter si une valeur a été mis à jour via une méthode de jeu. Cela ne va pas créer un anti-modèle et presque jamais en être la cause du problème.
On pourrait dire, si vous pouvez facilement abuser de l'AOP pour créer beaucoup de problèmes, c'est une mauvaise idée de l'utiliser. Cependant, la technologie ne peut pas être abusé? Vous pouvez l'abus de l'encapsulation de données, vous pouvez l'abus de l'héritage. Presque tous utiles de la technologie de programmation peuvent être victimes de violence. Considérons un langage de programmation si limité qu'il ne contient que des fonctionnalités qui ne peuvent pas être victimes de violence; une langue où les fonctions ne peuvent être utilisées, car elles étaient à l'origine destinés à être utilisés. Un tel langage serait être limité de telle sorte qu'on peut se demander si il peut même être utilisé pour de vrai monde de la programmation.
