Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Drawbacks of AOP 
I think the concept of shyness, taken from Adaptive Programming, will be a key 
concept to solve the awareness problem discusses here. The AP definition of 
shyness is:

  A concern C is X-shy if the C implementation can adapt to small changes in X,
  or if the C implementation relies only on minimal information of X
  implementations.

The demeter system is useful for structure-shy programming. Demeter includes the 
ability to write visitors as a language construct. Suppose you have a hairy 
class graph:

  University
  +-College (0..*)
    +-Library (0..*)
      +-Book (0..*)

(The class graph shows a University class, which contains zero or more Colleges, 
which contains zero or more Libraries, which contains zero or more Books.) To 
obtain a list of every Book in the University, you would specify the traversal 
path:

   declare strategy: everyBook: "from Unviersity to Book";
   declare traversal: void visitBooks(): everyBook (MyBookVisitor);

With these two lines Demeter will add the visitBooks method to the University 
class. All of the vistor methods (in College, Library, and Book) are written 
automatically. If the structure of the program changes (for example, the College 
class is eliminated, or a Shelf class is added) the traversal code stays the 
same. (More advanced paths can be expressed as well, composing different path 
rules to bypass classes or gaurantee a certain class is on the path).

Now here's the important difference between encapsulation and shyness: In 
AspectJ, you can encapsulate (i.e. separate) the visitor concern in its own 
aspect (using inter-type declarations), but the aspect isn't free from changes 
to the structure: the AspectJ solution to separating the visitor concern 
duplicates information already contained in the class graph. Therefore, changes 
in the class graph means there will need to be changes in the aspect too. The 
more adaptable aspects are the less I see the fundamental idea of AOP being a 
drawback.

I think sucessful domain-specific aspect languages include constructs on the 
program level. For example, in Demeter you compute with the class graph of the 
program. In RG (a DSAL that's fallen off of the face of the earth) you compute 
with the data-flow diagram of the program. Maybe the concept of shyness can 
encourage you to think of other aspect languages.

-Macneil

Adaptive programming link:
 http://www.ccs.neu.edu/research/demeter/
 http://daj.sourceforge.net/ (DAJ: DemeterJ plus AspectJ in one tool)


> Just some random thoughts on the matter...
> 
> Is this not one of the key elements of AOP - that the affected code need
> not know that the aspect exists because it is an aspect of the system
> that may affect one pointcut this compile and another the next.
> Implementation of standard programming practices (avoid side-effects,
> etc.) will help to ensure that aspects will not affect the system in a
> harmful manner.  Use of tools will ensure that we can see how the
> aspect-oriented system is composed.  
> 
> One key concern that may be had is that harmful aspects will be written.
> Tools can help us identify where aspects are affected, and if a pointcut
> applies to a portion of code that we didn't expect, re-write the
> pointcut to be more exact.  
> 
> John Rayburn
> Threewide Corporation
> 304.594.8081 mailto:jrayburn@xxxxxxxxxxxxx
> 
> 
> -----Original Message-----
> From: Maximilian Stoerzer [mailto:stoerzer@xxxxxxxxxxxxxxxxxxxxxxxxx] 
> Sent: Tuesday, April 15, 2003 10:11 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Drawbacks of AOP
> 
> Hi everybody!
> 
> I think there is a difference in OO and AOP. In OO, you have a 
> structured way to find out which method is actually called by simply 
> making your way up the inheritance hierarchy.
> 
> In AOP you can not do that, at least not as it is implemented in 
> AspectJ. Without tool support you might not even be aware of an aspect 
> influencing (or even replacing) a method you are calling.
> 
> Any aspect can globally influence any method of the system. There is no 
> structured way to find out what functionality is actually executed by 
> reading the source of a class anymore.
> 
> So I think the problem about "awareness" is quite important - that's why
> 
> there is so much effort to create tools to reveal this influence.
> 
> Best Regards,
>     Max
> 
> Robert Wenner wrote:
> 
> >I wonder how much this "aware of the aspect" problem counts in some 
> >years...
> >
> >After all, we already got used to overwriting methods. 
> >Or does anybody reject OO because it isn't  as obvious as in 
> >traditional C programming which method will in fact be called?
> >
> >Robert
> >_______________________________________________
> >aspectj-users mailing list
> >aspectj-users@xxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >  
> >
> 
> -- 
> Maximilian Stoerzer
> Lehrstuhl Software Systeme - FMI - University of Passau
> Tel: +49 851 509 3096, eMail: stoerzer@xxxxxxxxxxxxxxxxx
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>

Back to the top