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
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
