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