Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Philosophical Questions

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

Back to the top