|
Cedric,
In the
middleware space, I would certainly agree that a library of pointcuts is
probably just as important as a library of fully defined aspects. When
interfacing with an established system, it would be very difficult for a new
developer to understand the control flow required to intercept a JMS message,
for example. In fact, for library writers in general, it would be an interesting
experiment to provide a series of pointcuts for use with AOP instead of built in
complex interceptor stacks (as Tomcat and Axis have done).
But I
think that one of the keys points with AspectJ is that even if you extend an
abstract aspect and reuse it's pointcuts, your advice is still defined relative
to the pointcut, not independent of it. If we assume that most advice is tightly
coupled with the pointcut or type of pointcut it depends on, then the separation
of these concepts becomes more of a burden than a benefit.
I
don't have anything against the dynamic AOP libraries at all. In fact I think
Jonas is doing some interesting and innovative things with AspectWerkz. Were it
my design, I would probably have unified the aspect components at the API level
rather than through descriptor files, and that's part of why I started this
thread - to see how others view this distinction, or even whether it even
matters.
Cheers,
Merrick
Gregor
writes:
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.
I am worried to see
terms such as "screenful" and "file" in a discussion that should be focused
exclusively on design.
These terms are related to tools, and they
should not have any bearing on the design of a framework. What you want
is an easy access to this information, and this can be provided by an
IDE.
AspectJ is based on Java, and the fundamental unit of
modularity in Java is the class, so I am really surprised to
read:
From that perspective, putting
pointcuts and advice bodies in separate files isn't what we
want.
Java programmers are
extremely proficient with classes. If you fail to acknowledge this fact,
you are fighting against the language and against its users. Rickard
recently voiced this concern the AOP Alliance mailing-list. Note that he
stressed that this limitation with AspectJ was a problem for him, and he made
it clear that things might be different for other users, but I believe his
concern is valid.
Separating advice and pointcuts in different classes
is even more important in the context of J2EE AOP. Leave it up to J2EE
vendors to provide sophisticated pointcuts so that the users can focus on
writing the business logic of their aspects without worrying about these
low-level details.
And then, leave it up to higher-level tools to
present the developer with a convenient view allowing them to quickly
distinguish pointcuts, join points, advice code in relation to the Java code
they apply to, etc...
In short, use every tool for what it is
specialized for.
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. Glad to hear
that. I believe the semantics of these tags might end up being more
"vague" than the traditional way to define pointcuts: they would be
hints that a weaver might or might not pick. I can see certain scenarios
where tagging the Java code would be more reliable than using a sophisticated
but fragile AspectJ regexp to locate the join point. However, it is
important to keep in mind that metadata fundamentally undermines the original
goal of AOP (separation of concerns) so it should be used very
sparingly.
--
Cédric
http://beust.com/weblog
|
