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
|