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

>But if you extract a Screen interface containing this method, you can 
>add the implementation via introduction. Then, it is obvious for 
>developers that this method is part of the interface of Screen, but the

>implementation can vary (note: using such an idiom also implies that
you 
>can easily switch from the pure static dispatching to the
pseudo-dynamic 
>dispatching without touching the source code of the involved classes).

Very true, another argument to put on my
zillions-of-reasons-to-program-against-interfaces-list.

Thank you very much Stefan.

btw, the performance has boosted up to (loop is now 10000000, i.e. times
10 compared to before):

Testing display of points using immediate method dispatching:70

Testing display of points using double dispatching:240

Testing display of graphical elements using instanceof and casting:250

Testing display of graphical elements using AOP:351

Rudi.


-----Original Message-----
From: Stefan Hanenberg [mailto:shanenbe@xxxxxxxxxxxxxxxxxxxxxxx] 
Sent: donderdag 10 juli 2003 15:19
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Using AOP to implement double dispatching
technique


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

In AspectJ you cannot override an abstract method inside a class using 
introductions. That means, it is not possible to specify the method 
inside Screen and then "override it" via an introduction (that was the 
intention of the around advice....).

But if you extract a Screen interface containing this method, you can 
add the implementation via introduction. Then, it is obvious for 
developers that this method is part of the interface of Screen, but the 
implementation can vary (note: using such an idiom also implies that you

can easily switch from the pure static dispatching to the pseudo-dynamic

dispatching without touching the source code of the involved classes).

-Stefan


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

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
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