Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Using AOP to implement double dispatching technique 
Thanks for the "advice" Stefan. Your solution sure looks much simpler
than mine.

I have one concern however. Introducing the
Screen.aoDisplay(GraphicalElement ge) method in the
ScreenGraphicalElementDDs aspect does indeed add the method as a
publically accessble method on the Screen class, but for anybody
accessing or reading the Screen class, it is not obvious that this
method exists.
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.
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law.  If you are not the intended recipient, you should
delete this message.  Any disclosure, copying, or distribution of this
message, or the taking of any action based on it, is strictly
prohibited.


-----------------------------------------------------------------------


This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law.  If you are not the intended recipient, you should delete this message.  Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.

Back to the top