Aspect-oriented programming: Difference between revisions

Revision as of 16:57, 14 July 2018

Revision as of 02:18, 4 October 2018

Line 195:

==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]], but is in fact closely analogous to the joke [[COME FROM]] statement. 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">"[https://pp.info.uni-karlsruhe.de/uploads/publikationen/constantinides04eiwas.pdf AOP Considered Harmful] {{webarchive|url=https://web.archive.org/web/20160304055622/http://pp.info.uni-karlsruhe.de/uploads/publikationen/constantinides04eiwas.pdf |date=2016-03-04 }}", Constantinos Constantinides, Therapon Skotiniotis, Maximilian Störzer, ''European Interactive Workshop on Aspects in Software'' (EIWAS), Berlin, Germany, September 2004.</ref><ref>[[C2:ComeFrom]]</ref> For example, compare the COME FROM program:<ref name="harmful"/>

<source lang="basic" highlight="4">

5 inputINPUT xX

10 printPRINT 'resultResult is :'

15 printPRINT xX

20 comeCOME fromFROM 10

25 xX = xX * xX

20 come from 10

30 RETURN

25 x = x * x

30 return

</source>

with an AOP fragment with analogous semantics:

<source lang="java" highlight="8">

main() {

input x

Line 213 ⟶ 212:

around(int x): call(result(int)) && args(x) {

int temp = proceed(x)

// return temp * temp

}

</source>

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.