AOP ... Dois-je désapprendre POO?
https://stackoverflow.com/questions/1325385
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'écument la documentation en ligne, lisez l'entrée wiki, les messages et les blogs, mais je suis toujours perplexe.
- Ce qui est, en un mot, Programmation Orientée Aspect ?
- Est-ce simplement mieux que la programmation orientée objet? Dois-je désapprendre POO?
- Sinon, comment puis-je savoir quand utiliser l'un ou l'autre? Quelles sont les principales différences entre les deux?
- Puis-je refact un dans l'autre?
Je l'ai toujours été un homme OO et je veux savoir si je dois commettre une trahison.
Sérieusement, je commence un nouveau projet bientôt et je veux faire les bons choix au début.
La solution
Qu'est-ce, en un mot, Programmation Orientée Aspect?
En un mot, AOP est la capacité d'injecter des actions dans le flux typique d'un autre programme, discrètement. Il vous permet de capturer instanciation de classe, les appels de méthode, missions, etc.
Est-il simplement mieux que la programmation orientée objet? Dois-je désapprendre POO?
Non et non. Il travaille en collaboration avec tous les environnements de programmation qui le soutient. (Voir ci-dessus).
Sinon, comment puis-je savoir quand utiliser l'un ou l'autre? Quelles sont les principales différences entre les deux?
Vous utilisez AOP, généralement, lorsque vous voulez mettre en œuvre une sorte d'actions sur des centaines de classes, sans manipuler les classes elles-mêmes. Des exemples typiques sont la sécurité (autorisation du droit d'appeler la méthode / classe donnée) ou l'exploitation forestière. Dans mon expérience, cependant, je ne l'utilise pas pour cela. (Je ne l'utilise pas du tout, honnêtement).
Comme ci-dessus, la principale différence n'existe pas vraiment, car ils ne sont pas comparables. Mais, dites que vous voulez mettre en œuvre la journalisation « normalement », vous appelez simplement l'enregistreur à des points appropriés:
log.write("hello");
Mais avec AOP, vous pouvez créer un « aspect » qui se fixe à chaque appel de méthode, et log « Méthode b appelée ». Le point est que dans « Shotgun » AOP vous approche est plus: vous attachez à tout, ou tout simplement un petit sous-ensemble. Ajout manuel d'exploitation forestière est généralement mieux.
Puis-je refact un dans l'autre?
Pas vraiment pertinent, voir d'autres réponses. Encore une fois avec la sécurité, vous pouvez échanger à un modèle AOP à partir d'un modèle POO typique this.IsAllowed () à quelque chose comme si (callingMethod.HasAttribute (foo)) {allowed = true; }
espère que ces réponses sont utiles. Faites-moi savoir si vous me voulez développer davantage.
Autres conseils
Non, AOP complète POO, plutôt que de se substituer à lui. AOP et POO offrent différents types de « colle » pour vous aider à combiner les comportements. POO, bien sûr, vous permet de combiner le comportement par héritage et de la composition, etc. AOP d'autre part vous permet d'ajouter des comportements pour faire face préoccupations transversales en interceptant href="http://en.wikipedia.org/wiki/Pointcut" où votre nouveau code court avant ou après les méthodes choisies des classes choisies.
Quelques exemples courants de préoccupations transversales sont: la sécurité, l'exploitation forestière et le contrôle des transactions. Un principe fondamental de la bonne conception est la cohérence: idéalement, un morceau de code doit faire une seule chose. Ainsi, il brouille l'eau pour ajouter du code de sécurité aux classes d'accès aux données, par exemple. AOP résout ce problème particulier en vous permettant d'ajouter le comportement dans un « Aspect », puis en appliquant cet aspect à toutes les classes qui devraient avoir des contrôles de sécurité.
AOP est différent de POO, des approches complètement différentes pour le développement.
En gros, si vous avez l'exploitation forestière, les problèmes d'authentification, le code de vérification de performance, ceux-ci seront les mêmes, à peu près, dans diverses parties du programme, dans les différentes classes. Ainsi, vous pouvez écrire votre application comme vous l'imaginez, en Java, lorsque vous devez ajouter dans ces autres types de code (préoccupations transverses) alors que vous venez de les injecter dans le programme, afin qu'ils puissent être compilés, mais quand vous regardez le code source, vous venez de voir la logique métier dont vous avez besoin là.
Quant à savoir quand utiliser AOP ou POO, je vous suggère d'écrire le programme, le faire fonctionner, lorsque vous avez fonctionne, regardez la suppression du code qui ne fait pas à voir avec la fonction, mais sert quelques-uns d'autres fins. Par exemple, si vous devez vérifier que les paramètres d'entrée sont corrects avant de les utiliser, utilisez un aspect pour cela. Si vous avez la gestion des événements similaires, comme toutes les exceptions jetées dans la couche d'accès aux données écrit dans un fichier journal, puis créer un aspect pour cela.
Comme vous supprimez ces transsectoriel concerne votre code rapetissent.
Comme vous obtenez plus d'expérience, vous verrez plus d'utilisations pour AOP, mais d'abord je suggère l'écrire, refactoriser puis en utilisant AOP.
Utiliser Eclipse, si vous utilisez Java, pour AOP, comme le plug-in AJDT sera très utile pour voir où vous ajoutez les aspects.
Programmation Orientée Aspect est un mot à la mode accrocheur pour insérer des actions (appelées « conseils ») dans des méthodes ou des fonctions à des points clés tels que les appels et les retours, entre autres. J'ai un gros problème avec AOP parce qu'elle viole tous les obstacles à l'abstraction construite dans la langue. Il n'y a aucun moyen pour un module de dire «c'est ce qu'un aspect peut jouer avec et voici ce un aspect ne peut pas mess avec. » Par conséquent, vous risquez de violer internes invariants, et vous détruire le principe de raisonnement modulaire (vous pouvez comprendre un module sans avoir à comprendre quoi que ce soit, mais les interfaces des autres modules qu'il importe).
Il y a quelques années Raymie Stata a écrit une thèse de doctorat brillante sur la façon dont les langages orientés objet peut contrôler subclassing et l'empêcher de violer invariants clés. Les travaux correspondants pour AOP n'a pas encore été écrit.
Alors que toute autre idée qui gagne la monnaie, AOP a connu quelques succès spectaculaires (par exemple, l'exploitation forestière modernisation d'une application non conçue avec l'enregistrement à l'esprit), dans l'ensemble, je vous encourage vivement à limiter votre utilisation de l'AOP à des cas très simples . Ou mieux encore, dire non à la programmation orientée aspect.
