Aspect-oriented programming: Difference between revisions

Revision as of 14:24, 19 April 2020

Revision as of 15:27, 20 April 2020

Line 24:

For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:<ref>Note: The examples in this article appear in a syntax that resembles that of the [[Java (programming language)|Java]] language.</ref>

<sourcesyntaxhighlight lang="java">

void transfer(Account fromAcc, Account toAcc, int amount) throws Exception {

if (fromAcc.getBalance() < amount)

Line 32:

toAcc.deposit(amount);

}

</syntaxhighlight>

</source>

However, this transfer method overlooks certain considerations that a deployed application would require: it lacks security checks to verify that the current user has the authorization to perform this operation; a [[database transaction]] should encapsulate the operation in order to prevent accidental data loss; for diagnostics, the operation should be logged to the system log, etc.

Line 38:

A version with all those new concerns, for the sake of example, could look somewhat like this:

<sourcesyntaxhighlight lang="java">

void transfer(Account fromAcc, Account toAcc, int amount, User user,

Logger logger, Database database) throws Exception {

Line 60:

logger.info("Transaction successful.");

}

</syntaxhighlight>

</source>

In this example other interests have become ''tangled'' with the basic functionality (sometimes called the ''business logic concern''). Transactions, security, and logging all exemplify ''[[cross-cutting concern]]s''.

Line 70:

So for the example above implementing logging in an aspect:

<sourcesyntaxhighlight lang="aspectj">

aspect Logger {

void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) {

Line 82:

// Other crosscutting code.

}

</syntaxhighlight>

</source>

One can think of AOP as a debugging tool or as a user-level tool. Advice should be reserved for the cases where you cannot get the function changed (user level)<ref>{{cite web|url=https://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Functions.html|title=gnu.org|website=www.gnu.org|accessdate=5 May 2018|url-status=live|archiveurl=https://web.archive.org/web/20171224053656/http://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Functions.html|archivedate=24 December 2017}}</ref> or do not want to change the function in production code (debugging).

Line 120:

Pointcuts can be composed and named for reuse. For example:

<sourcesyntaxhighlight lang="aspectj">

pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*);

</syntaxhighlight>

</source>

This pointcut matches a method-execution join point, if the method name starts with "<code>set</code>" and <code>this</code> is an instance of type <code>Point</code> in the <code>com.company</code> package. It can be referred to using the name "<code>set()</code>".

Line 143:

''Inter-type declarations'' provide a way to express crosscutting concerns affecting the structure of modules. Also known as ''open classes'' and ''[[extension method]]s'', this enables programmers to declare in one place members or parents of another class, typically in order to combine all the code related to a concern in one aspect. For example, if a programmer implemented the crosscutting display-update concern using visitors instead, an inter-type declaration using the [[visitor pattern]] might look like this in AspectJ:

<sourcesyntaxhighlight lang="aspectj">

aspect DisplayUpdate {

void Point.acceptVisitor(Visitor v) {

Line 150:

// other crosscutting code...

}

</syntaxhighlight>

</source>

This code snippet adds the <code>acceptVisitor</code> method to the <code>Point</code> class.

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.<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|accessdate=5 May 2018|url-status=live|archiveurl=https://web.archive.org/web/20160323061458/https://pp.info.uni-karlsruhe.de/uploads/publikationen/constantinides04eiwas.pdf|archivedate=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"/>

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

5 INPUT X

10 PRINT 'Result is :'

Line 202:

25 X = X * X

30 RETURN

</syntaxhighlight>

</source>

with an AOP fragment with analogous semantics:

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

main() {

input x

Line 214:

return temp * temp

}

</syntaxhighlight>

</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.