[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] Philosophical Questions
|
Title: Message
One of the guiding principles of the AspectJ design was
that we were trying to enable modular implementation of crosscutting concerns --
aka aspects. That is what led us to put pointcuts, advice and other member
declarations together into aspects. For example, being able to see the entire
ObserverProtocol aspect in a single screenful of code was important to us.
It gave us the nice modularity we were after. I personally believe that is
critical, that's what separation of concerns is about, getting the concerns into
separate modular pieces.
From that perspective, putting pointcuts and advice
bodies in separate files isn't what we want.
But what I don't understand is to what degree tool
support will be able to bring the separate things back together. One of the
claims about XML and meta-data is that of course you'll never edit the raw
meta-data or XML, there will be tool support. If there is tool support, then
that support might be able to make things look more modular. But then again,
everytime I see someone talking about XML they insist on showing me the raw XML,
so I'm not sure how present the tool support is.
3)
What role, if any, should metadata play in AOP?
I know Gregor has commented on the use of
metadata a couple of times, but the JBoss group is charging ahead with their
"AOP" product which encourages developers to use class metadata to load
library aspects. This strikes me as wrong in many ways, but the message that
is reaching the development community is that interceptors and metadata are
all you need to do AOP. Is this just a function of what's easy to implement,
or are people really having trouble grasping the concepts?
My opinion on this has softened. I now believe that
meta-data support (ala JSR-175) is useful, and that when it appears in Java,
tools like AspectJ should support it instantly. I think programmers should use
attributes (aka tags or metadata) in pointcuts in certain circumstances when
property-based or enumeration based pointcuts are not appropriate. Without going
into detail, I think the 3 cases are:
- if the pointcut reaches a large number of join
points, use a property based pointcut
- if the pointcut reaches a small number of join
points, and a property-based pointcut is hard to write, use
tags
- if the pointcut reaches a small number of join
points, and a property-based pointcut is hard to write, and you don't have
access to the target source, then use an enumeration-based
pointcut.