Over the last year, I’ve addressed a number of specific issues related to aspect-oriented programming (AOP), including keys to adoption, basic concepts, common misconceptions, IDE support and emerging industry support. This month, I want to step back from those details to take a look at the bigger picture: the impact aspect-oriented programming will have, and what we know today about how the technology will play out.
Before getting to aspects, imagine a simple drawing application that lets users draw, color and move points, lines, rectangles and circles. Now think for a minute about implementing this application.
What kinds of design and code elements are you thinking about? I’ll bet you’re envisioning domain objects such as points, lines and other shapes, as well as infrastructure objects such as menus and drawing surfaces.
Now here’s some important history: In 1965, 99 percent of programmers would have thought of a very different structure, using tables of x and y coordinates for points, other tables for lines and so on. Then they’d have had a collection of procedures for operating on the tables. This would have lacked the nice modularity of the object solution—the code for points and lines would be scattered and tangled. And it would have involved a great deal of complexity in terms of managing space in the tables and references between them, even though that really has nothing to do with the application domain. (In fact, even in 1980, many programmers wouldn’t have thought of the object structure.)
But today, even if you had to implement this program in ordinary C, you’d almost certainly use an object-oriented style of some sort. You might have structs for the points and lines, and you would group the code for each kind of struct to the greatest degree possible.
The table-based approach wouldn’t even occur to you. It’s hard to prove that, of course, since it’s a little like saying, “I bet you’re not thinking of a pink elephant.” But I think it’s true.
You may feel that when you saw this application, you instinctively modeled it with objects. As I’ve said, however, it wasn’t always that way. In the past, our collective instinct would have been to handle it differently. So the impact of OO has been both profound and subtle. It has changed our instinct and how we think, not just how we program.
Aspect Instinct
AOP is in the early stages of having a similar effect. Already, when an experienced AOP programmer thinks about these applications, he instinctively sees other design elements. In addition to seeing objects like points, lines and menu items, he sees aspects such as grouping, geometric constraints and (the well-worn) display updating.
At the ServerSide Java Symposium held in Las Vegas in May, this discussion of aspects as elements of a system was very much in evidence. While people were talking about the details of specific AOP frameworks like AspectJ, JBoss, Spring and DynAOP, much of the buzz was about aspects themselves. Can a distributed caching scheme be handled as an aspect? How can a transaction aspect written for Spring be used with AspectJ?
The Future
What does this all bode for AOP?
First, the biggest impact is already happening: The concepts of aspects and crosscutting are becoming part of our everyday discourse and how we think about systems. A growing number of people now think instinctively about aspects, even if they have to program in plain Java or C#.
Second, in the long run, thinking aspects is more important than any specific AOP tool. Recognizing this, active AOP developers are moving into this higher-value area of the AOP exploration space by focusing on the aspects, rather than worrying about the trends in the AOP tool space. This involves some risk, because the actual AOP tools we use are still changing, but this risk is less significant than it appears to be, and amply compensated for by the gain. For one thing, porting a program back and forth between tools isn’t that hard, since they all share a common underlying model. So the cost of moving to a completely different AOP tool is modest. The cost of updating between releases of a specific tool is much less; usually zero for the more mature tools.
The gain from working in the aspect space is significant. There are immediate benefits to the code you’re working on, and you’re getting a head start on the most important aspect of AOP: how to think in terms of aspects. I say “aspect of AOP” on purpose, because thinking aspects crosscuts how we think about system design. So learning it, really getting good at it, and seeing how to be strategic with aspects has crosscutting implications and will take time. It’s not difficult, and just working with AOP is the best way to learn, but, like OO design, it’s something you’ll get better at with practice. By starting now, taking the small risk of having to change your aspect code, you’re accelerating your investment in learning the real value of aspects.
In the next couple of years, we’ll see the continued evolution of AOP tools. We’ll see convergence on the common features, as well as continued variance in newly discovered features. During this time, developers who use these tools, despite the flux, will get immediate gain in their code and cultivate their aspect design instincts. They’ll be the first to glean the biggest benefits from aspects.
Gregor
Kiczales led the Xerox PARC teams that developed aspect-oriented
programming and AspectJ, and is a leading AOP evangelist based in Vancouver.
