Editing Aspect-oriented programming (section)

==Criticism==
The most basic criticism of the effect of AOP is that control flow is obscured, and that it is not only worse than the much-maligned [[GOTO]] statement, but is closely analogous to the joke [[COME FROM]] statement.<ref name="harmful"/> The ''obliviousness of application'', which is fundamental to many definitions of AOP (the code in question has no indication that an advice will be applied, which is specified instead in the pointcut), means that the advice is not visible, in contrast to an explicit method call.<ref name="harmful">{{cite conference|url=http://pp.info.uni-karlsruhe.de/uploads/publikationen/constantinides04eiwas.pdf |title=AOP Considered Harmful |first1=Constantinos |last1=Constantinides |first2=Therapon |last2=Skotiniotis |first3=Maximilian |last3=Störzer|date=September 2004|access-date=5 May 2018|url-status=live|archive-url=https://web.archive.org/web/20160323061458/https://pp.info.uni-karlsruhe.de/uploads/publikationen/constantinides04eiwas.pdf|archive-date=23 March 2016|conference=European Interactive Workshop on Aspects in Software (EIWAS) |location=Berlin, Germany}}</ref><ref>[[C2:ComeFrom]]</ref> For example, compare the COME FROM program:<ref name="harmful"/>
<syntaxhighlight lang="basic" highlight="4">
 5 INPUT X
10 PRINT 'Result is :'
15 PRINT X
20 COME FROM 10
25      X = X * X
30 RETURN
</syntaxhighlight>
with an AOP fragment with analogous semantics:
<syntaxhighlight lang="java" highlight="8">
main() {
    input x
    print(result(x))
}
input result(int x) { return x }
around(int x): call(result(int)) && args(x) {
    int temp = proceed(x)
    return temp * temp
}
</syntaxhighlight>
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">{{Cite journal |doi=10.1145/1167515.1167514 |title=The paradoxical success of aspect-oriented programming |journal=ACM SIGPLAN Notices |volume=41 |issue=10 |pages=481–497 |year=2006 |last1=Steimann |first1=F. |citeseerx=10.1.1.457.2210}}, ([http://people.dsv.su.se/~johano/ioor/succ_aop.pdf slides] {{webarchive|url=https://web.archive.org/web/20160304060007/http://people.dsv.su.se/~johano/ioor/succ_aop.pdf |date=2016-03-04}},[http://www.eecs.ucf.edu/~leavens/modular-aop/Discussion.pdf slides 2] {{webarchive|url=https://web.archive.org/web/20150923234021/http://www.eecs.ucf.edu/~leavens/modular-aop/Discussion.pdf |date=2015-09-23}}, [http://www.oopsla.org/2006/submission/essays/the_paradoxical_success_of_aspect-oriented_programming.html abstract] {{webarchive|url=https://web.archive.org/web/20150924060711/http://www.oopsla.org/2006/submission/essays/the_paradoxical_success_of_aspect-oriented_programming.html |date=2015-09-24}}), 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|access-date=11 August 2015|url-status=live|archive-url=https://web.archive.org/web/20150812045258/http://www.eecs.ucf.edu/~leavens/modular-aop/|archive-date=12 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>{{cite web|url=http://www.fernuni-hagen.de/ps/pubs/FOAL2006.pdf|title=AOP and the Antinomy of the Liar|website=fernuni-hagen.de|access-date=5 May 2018|url-status=live|archive-url=https://web.archive.org/web/20170809201001/http://www.fernuni-hagen.de/ps/pubs/FOAL2006.pdf|archive-date=9 August 2017}}</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, which AOP was designed to solve.<ref name="steimann"/>