Aspect-oriented programming: Difference between revisions

Revision as of 07:13, 26 August 2015

Revision as of 15:54, 28 August 2015

Line 12:

==History==

AOP has several direct antecedents A1 and A2:<ref>{{citeCite conference doi| doi = 10.1007/BFb0053381| title = Aspect-oriented programming| work = Proceedings of the 11th European Conference on Object-Oriented Programming| conference = [[European Conference on Object-Oriented Programming|ECOOP]]'97| volume = 1241| pages = 220–242| series = [[Lecture Notes in Computer Science|LNCS]]| year = 1997| last1 = Kiczales | first1 = G. | author1-link = Gregor Kiczales | last2 = Lamping | first2 = J. | last3 = Mendhekar | first3 = A. | last4 = Maeda | first4 = C. | last5 = Lopes | first5 = C. | last6 = Loingtier | first6 = J. M. | last7 = Irwin | first7 = J. | isbn = 3-540-63089-9| id = {{citeseerx|10.1.1.115.8660}}| url = http://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf}}</ref> [[reflection (computer programming)|reflection]] and [[Metaobject|metaobject protocol]]s, [[subject-oriented programming]], Composition Filters and Adaptive Programming.<ref>"Adaptive Object Oriented Programming: The Demeter Approach with Propagation Patterns" ''Karl Liebherr'' 1996 ISBN 0-534-94602-X presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).</ref>

[[Gregor Kiczales]] and colleagues at [[Xerox PARC]] developed the explicit concept of AOP, and followed this with the [[AspectJ]] AOP extension to Java. IBM's research team pursued a tool approach over a language design approach and in 2001 proposed [[Hyper/J]] and the [[Concern Manipulation Environment]], which have not seen wide usage. The examples in this article use [[AspectJ]] as it is the most widely known AOP language.{{Citation needed|date=November 2010}}

Line 219:

Indeed, the pointcut may depend on runtime condition and thus not be statically deterministic. This can be mitigated but not solved by static analysis and IDE support showing which advices ''potentially'' match.

General criticisms are that AOP purports to improve "both modularity and the structure of code", but some counter that it instead undermines these goals and impedes "independent development and understandability of programs".<ref name="steimann">{{citeCite journal doi| doi = 10.1145/1167515.1167514| title = The paradoxical success of aspect-oriented programming| journal = ACM SIGPLAN Notices| volume = 41| issue = 10| pages = 481| year = 2006| last1 = Steimann | first1 = F. }}, ([http://people.dsv.su.se/~johano/ioor/succ_aop.pdf slides],[http://www.eecs.ucf.edu/~leavens/modular-aop/Discussion.pdf slides 2], [http://www.oopsla.org/2006/submission/essays/the_paradoxical_success_of_aspect-oriented_programming.html abstract]), Friedrich Steimann, Gary T. Leavens, [[OOPSLA]] 2006</ref> Specifically, quantification by pointcuts breaks modularity: "one must, in general, have whole-program knowledge to reason about the dynamic execution of an aspect-oriented program."<ref>{{cite web|url=http://www.eecs.ucf.edu/~leavens/modular-aop/|title=More Modular Reasoning for Aspect-Oriented Programs|publisher=|accessdate=11 August 2015}}</ref> Further, while its goals (modularizing cross-cutting concerns) are well-understood, its actual definition is unclear and not clearly distinguished from other well-established techniques.<ref name="steimann"/> Cross-cutting concerns potentially cross-cut each other, requiring some resolution mechanism, such as ordering.<ref name="steimann"/> Indeed, aspects can apply to themselves, leading to problems such as the [[liar paradox]].<ref>[http://core.ac.uk/download/pdf/11558418.pdf AOP and the Antinomy of the Liar]</ref>

Technical criticisms include that the quantification of pointcuts (defining where advices are executed) is "extremely sensitive to changes in the program", which is known as the ''fragile pointcut problem''.<ref name="steimann"/> The problems with pointcuts are deemed intractable: if one replaces the quantification of pointcuts with explicit annotations, one obtains attribute-oriented programming instead, which is simply an explicit subroutine call and suffers the identical problem of scattering that AOP was designed to solve.<ref name="steimann"/>

Line 286:

==Further reading==

* {{Cite conference | doi = 10.1007/BFb0053381| title = Aspect-oriented programming| work = Proceedings of the 11th European Conference on Object-Oriented Programming| conference = [[European Conference on Object-Oriented Programming|ECOOP]]'97| volume = 1241| pages = 220–242| series = [[Lecture Notes in Computer Science|LNCS]]| year = 1997| last1 = Kiczales | first1 = G. | author1-link = Gregor Kiczales | last2 = Lamping | first2 = J. | last3 = Mendhekar | first3 = A. | last4 = Maeda | first4 = C. | last5 = Lopes | first5 = C. | last6 = Loingtier | first6 = J. M. | last7 = Irwin | first7 = J. | isbn = 3-540-63089-9| id = {{citeseerx|10.1.1.115.8660}}| url = http://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf}} The paper generally considered to be the authoritative reference for AOP.

* {{cite doi|10.1007/BFb0053381}} The paper generally considered to be the authoritative reference for AOP.

* {{cite book | author = Andreas Holzinger, M. Brugger, W. Slany | year = 2011 | title = Applying Aspect Oriented Programming (AOP) in Usability Engineering processes: On the example of Tracking Usage Information for Remote Usability Testing.|others=D. A. Marca, B. Shishkov and M. v. Sinderen (editors)|work=Proceedings of the 8th International Conference on electronic Business and Telecommunications. Sevilla|pages=53–56}}

* {{cite book | author = Robert E. Filman, Tzilla Elrad, Siobhán Clarke and Mehmet Aksit| year = 2004 | title = Aspect-Oriented Software Development | isbn = 0-321-21976-7}}