(I’m CC’ing users on this message because that’s where the unit
testing discussion took place)
The idea of named
advice has popped up a few times. Usually it’s because someone wants
*labels* for advice, e.g. for the IDE’s outline view, or for the stack trace
entry in a debugger thread tree. But labels are not the same thing as
names and could be added with an annotation on the advice. Names are
used to invoke things explicitly. The beauty and utility of advice comes
from it being invoked implicitly as the result of join point
matching.
Recently another use
case for naming advice popped up on the list, as a means of explicitly
invoking advice so that it can be unit tested. In my opinion advice are
not methods, and can not be unit tested in the same way that methods
can. When you unit test methods you need to mock up the object
parameters to the method, and then invoke it explicitly. It seems to me
that when you’re unit testing advice you need to mock up the join point
context in a way that invokes the advice implicitly (i.e. create some kind of
join point context object that causes the appropriate pointcut to match by
specifying signatures and type patterns, setting the values of any args(),
this() and target() referenced, and possibly setting up anything needed from a
cflow stack). Then you pass your join point context and an aspect type
reference to a unit testing framework which is responsible for invoking the
corresponding advice. If you don’t care about all that context stuff,
and really just want to unit test the body of the advice, then simply create a
method for the body, make the only line in the advice a call to the method,
and unit test the method.
Jean-Sebastien, you
bring up a third use case: adding names so that advice can be more easily
matched by a pointcut. In AspectJ 5 I already think that it’s convenient
enough. You’ve always been able to match advice using within(), and now
you’ll be able to match it using annotations on the advice. But I’ve
never seen a compelling use case for this, other than someone suggesting that
they might want to log all advice. Again, they can do that without
naming.
Other people’s
opinion on this may differ, but I see no need to make advice more like methods
by giving them names. When you want implicit invocation based on join
point matching, you use advice. When you want explicit invocation by
name, you use methods. Naming advice will muddy those waters. As
you point out, it will also add OOP inheritance facilities (e.g. overriding)
to advice. AspectJ’s stance is that AOP inheritance is about abstracting
and concretizing pointcuts, and not about extending and overriding
behavior. Notably other approaches such as JBoss AOP and Spring AOP
provide the latter for advice by using method names for them, so we’ll learn
more about those consequences of that approach before too
long.
So in short, I still
haven’t heard a compelling use for naming advice. But a discussion of
these and other potential uses of naming advice could be a useful research
contribution.
Mik
From:
aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Jean-Sebastien Boulanger
Sent: Friday, February 18, 2005
11:44 AM
To: aspectj-dev@xxxxxxxxxxx
Subject: [aspectj-dev] Named Advice
revisited.
As an experimental project I'm
currently looking into extending aspectJ syntax using the aspectbench compiler
(www.aspectbench.org) to support
named advice. The extension will support pointcut that can match advices
by name.
I'm also trying to figure out
what should be the overriding rules for the named advice (if you can
override or not a named advice in a sub-aspect) and I red in the archive of
the mailing list that the idea that a named advice could override/extend
advices with the same name is 'truly frightening'. I'm not sure I understand
conceptually why it is so frightening, maybe my mind is still thinking OO
too much...anyway it would be very appreciated if someone could explain
to me in more details???