Channels ▼

Thinking Aspects

Thinking Aspects

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.