« What is this? | Main | "Breakthrough Ideas" - The Acceptability Envelope »

Aspects from afar

Tuesday @ oopsla

This has been the first year I've really taken a close look at aspects due to my work at G2, particularly in reference to Spring, so I decided to sit in on this lecture in order to get a bit more perspective on aspects "in the large". I can't say I changed my mind very much about aspects (I still think it holds some promise, but I'm also still skeptical), but I think I've been able to think a bit better about what I do and don't like about aspects.

After remarking that everyone seems to talk exclusively about aspects with respect to extending legacy systems or extending a 3rd party codebase, someone asked the panel why nobody spends much time talking about using aspects in new development (i.e. designing with aspects in mind). Dave Thomas responded that [paraphrase], you probably won't be able to see these cross-cutting concerns early enough starting out, unless the problem domain is very well understood. I find that statement rather curious, since it could be argued that it either reflects an inability to wrap our heads around aspects as a tool to help us reason about the world, or else limits the real impact aspect programming can have on a system.

From my point of view, I like aspects for what they do, not for what they are. They are a code-centric tool, not a reasoning tool. When you start designing a system, so much time is spent reasoning around the code, I can't really see that aspects would be as helpful as other tools. I remember first learning about OO and the first OO program that made me think different about programming in general. OO may not reflect "real world" things, but they always helped me reason about the world. I never talk about cross-cutting concerns in the "real world". That's not to say they don't exist, just that they are artifcats of a world that has been thought through-- not constructs that helped build that world. What people like about cross-cutting concerns almost always relates back to code, never about the formulation and categorization of ideas.

Everybody likes good looking code, but as a general rule, I like things that help me reason about the world better. Or maybe I just haven't seen anyone talk about aspects in a way that has made me go "Wow!".

In response to the question of whether or not all features could be treated as aspects (which probably speaks more to the previous point), I believe it was Gregor Kiczales who mused somewhat sarcastically that anyone who could define exactly what "cross-cutting concern" means should try to provide a good definition of the word "object". He later went on to talk about about people thinking (incorrectly) that aspects == optional, but back-stepped a bit on that point when it was challenged by Jack Greenfield. To be honest, I didn't quite follow the subtext of what was going on there-- if nothing else, I felt the exchange was a bit distracting. I really don't care if aspects are considered of as "optional" components of the application (I'm guessing things like logging were being addressed). Chances are (again, we experienced this at G2) that you'll make mistakes along the way, and to the extent that dealing with mistakes is not optional, aspects are probably not an "optional" part of a given application.

The final comment I'll leave is Dave Thomas wondering if promoting aspects as a tool isn't like supplying needles to addicts-- so we don't really know what they'll do. I share his view that we may have a long way to go in understanding this all.

Miscellaneous points:

  • How to properly version pointcuts along with code?
  • Learning how to read pointcuts (string matching is one of the weakest parts of AOP).
  • Naming conventions are the answer? Need to stress naming conventions.


TrackBack URL for this entry:

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)