[aosd-discuss] [aspectj-users] AOP breaks modularity question

[Dean Wampler]

On Jan 22, 2008, at 2:29 AM, Luca Ferrari wrote:

> Hi all,
> I don't want to start a flame and my question is not really the one  
> in the
> subject. I often heard than there's a group of people saying that  
> AOP breaks
> modularity, and another (which I agree with) that says that it  
> improves
> modularity. One reason used from the latter is that the OOP  
> programmers
> usually breaks modularity to reach their aims. This is the sentence  
> I'd like
> to investigate, because I'm not sure I get it well. I think that,  
> since
> modules must combined together to build up a complete system, such  
> modules
> must provide ways to interact each other, thus breaking their  
> modularity or
> better their "isolation". Is this what that sentence means? Any  
> pointer to
> documentation, examples, or papers?
>

This is a good topic for "aosd-discuss", so I added that list.

The main way to break modularity with an aspect is to write pointcuts  
that refer to concrete details in classes or interfaces. Details  
change as code is refactored. For example, if I write a pointcut that  
refers to the "name" field in a "Person" class, as soon as I refactor  
Person to use "firstName" and "lastName", my aspect breaks. The  
standard refactoring tools in IDEs don't know how to modify pointcuts.  
Indeed, even if they could modify pointcuts, they may not know when  
they should modify a pointcut that uses wildcards.  For example, if my  
pointcut contains this expression, "set(* Person.n*)", should the IDE  
change it when I refactor "name"? How would it know?

This problem was documented a few years ago in an AOSD workshop paper  
that coined the phrase "AOSD Evolution Paradox" to describe the  
problem (http://citeseer.ist.psu.edu/716669.html). I forget if they  
coined the term, but you also hear such pointcuts called "fragile  
pointcuts".

I think this is a classic case of forgetting what we already knew;  
namely, we know from OOSD practice that your dependencies should point  
to abstractions. The Dependency Inversion Principle (http://www.objectmentor.com/resources/articles/dip.pdf 
) illustrates how to do this with objects. The trick for us is to  
figure out what DIP means for aspects, in particular, for pointcuts.

I gave a paper about this at last-year's AOSD conference (http://aosd.net/2007/program/industry/I6-AspectDesignPrinciples.pdf 
, see also the list of references there) and Norbert wrote about it a  
few years earlier (http://scholar.google.com/scholar?hl=en&client=safari&rls=en-us&q=author:%22Nordberg+III%22+intitle:%22Aspect-Oriented+Dependency+Inversion%22+&um=1&ie=UTF-8&oi=scholarr 
).

Sullivan's and Griswold's work on crosscutting programming interfaces  
(XPIs - see their IEEE Software paper, Jan/Feb. 2006 and google their  
other papers) and Jonathan Aldrich's work on "Open Modules", among  
others, demonstrate different ways to write pointcuts that couple to  
abstractions and solve the AOSD Evolution Paradox.

So, aspects can improve modularity, but only if we don't introduce new  
problems with fragile pointcuts.

dean

>
> Thanks,
> Luca
> _______________________________________________
>

Dean Wampler, Ph.D.
dean at objectmentor.com
http://www.objectmentor.com
See also:
http://www.aspectprogramming.com  AOP advocacy site
http://aquarium.rubyforge.org     AOP for Ruby
http://www.contract4j.org         Design by Contract for Java5



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20080122/0c13ee30/attachment.html