How about javadoc? Will the method be included in the javadoc of the
Screen class? Any comments here?
I wanted to make the display(GraphicalElement ge) method part of the api
of the Screen class to avoid the javadoc problem above. By doing so
however, I found it very hard to call the methods I had introduced on
GraphicalElementDisplayDispatchingDefaultImplementation. The compiler
would simple refuse to compile the code and that is why I resorted to
advice code.
Rudi.
-----Original Message-----
From: Stefan Hanenberg [mailto:shanenbe@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: donderdag 10 juli 2003 13:51
To: aspectj-users@xxxxxxxxxxx; Vankeirsbilck, Rudi. (BE - Merelbeke)
Subject: Re: [aspectj-users] Using AOP to implement double dispatching
technique
Hi Rudi,
I think you are mixing up 2 different techniques in your implementation:
- static dispatching (like usual Java-code, but now using introduced
methods)
- "dynamic" dispatching (using dynamic pointcutcut designators, advice,
etc.)
Within your code your have both implemented:
- the after advice rather looks like a dynamic dispatcher (by the way:
you should use an around advice)
- the introduced methods "displayOn" are the "real" static
double-dispatchers
Since you seem to be concerned about performance and contamination of
classes, your should skip the advice/pointcut and move everything
belonging to the double dispatching to an aspect:
- introduce "display(GraphicalElement ge)" to class Screen.
- introduce a "displayOn (Screen screen)" to Point and Line.
So, the code should look like:
aspect ScreenGraphicalElementDDs {
public void Screen.aoDisplay(GraphicalElement ge) {
ge.aoDisplayOn(this);
}
public void (Point || Line).aoDisplayOn(Screen s) {
s.display(this);
}
declare parents: (GraphicalElement) extends AODisplay;
}
interface AODisplay {
public void aoDisplayOn(Screen s);
}
Some remarks:
1. you could put the code for performance measurement to an aspect 2.
from my point of view GraphicalElement should not contain the double
dispatch method: instead this should be shifted to an aspect
3. I am still accustomed to AspectJ 1.06 and i am not familiar with how
introductions are now specified. Maybe the introductions like (Point ||
Line) are no longer valid in 1.1 and you have to add 2 different
introductions to it.
Regards,
Stefan
Vankeirsbilck, Rudi. (BE - Merelbeke) wrote:
Hi all,
First some introduction on double dispatching, my actual question is
below.
Very frequently, I use the double dispatching technique to solve the
following problem:
Consider 4 classes, A, B, C and T where A is the abstract superclass
of
B and C, T is a third party (i.e. with respect to A, B and C).
The latter needs to process A's and has different processing for B and
C
types of A. You can image that there will be a method like
public void process (A anA)
defined on the T class.
Most people will implement this method as:
public void process (A anA) {
if (anA instanceof B) {
B aB = (B) anA;
/* include code to process B objects
}
else {
C aC = (C) anA;
/* include code to process C objects
}
}
some may even introduce separate methods to actually process B and C.
In addition, I typically introduce a method on A, B and C such as the
following:
public abstract void process (T aT);
Classes B and C implement this abstract method to call the two methods
on T that deal with processing Bs and Cs.
The implementation of the process (A anA) method on the T class then
simply calls the process method on A, passing this as an argument.
In doing that, I am actually using polomorphism or Java's method
dispatcher to implement the if-then-else.
The primary advantage of the above technique is that when new
subclasses
of A are introduced there is no need to modify the process method
(maybe
the if-then-else appears in more locations that in the process
method),
al we need to do is add a new process method on the T class that
accepts
the new subclass of A.
A disadvantage is that I am actually contaminating A.
I know that most of you will know the above technique but that was
just
as an introduction.
While I was looking into AOP (finally), I will come as no surprise
that
AOP seemed like an excellent way to implement the double dispatching
technique without contaminating A.
HERE IS MY ACTUAL QUESTION:
I succeeded in implementing it using AOP but I would like some
confirmation of more experience guys like you all that there is no
better way to do it in AOP. You will find my code attached in
ddusingaop.zip
Also, I discovered that there is a performance penalty for AOP. The
AOPPerformanceTester class prints out the following:
Testing display of points using immediate method dispatching:10
Testing display of points using double dispatching:20
Testing display of graphical elements using instanceof and casting:30
Testing display of graphical elements using AOP:110
The first 3 are in line with my expectations, but the last one is a
bit
of a surprise. I looked at the generated code (using a decompiler
because I could not find an obvious way to look at the generated .java
file) and I found that the display method (which is post-processed by
the aspect) is actually called twice. Is this related to my
implementation or is this a problem of ajc?
Many thanks for having a look at my question,
Regards,
Rudi.
