Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] AOP breaks modularity question


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.


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
See also:
http://aquarium.rubyforge.org     AOP for Ruby
http://www.contract4j.org         Design by Contract for Java5




Back to the top