Channels ▼

Double Decker

Double Decker

I wish someone would show me an example of aspect-oriented programming that isn't logging. This is nearly a "perma-post on blogs and newsgroups discussing AOP. People say it, but it ain't so. Many published examples of AOP aren't logging, and serious AOP proponents rarely use it as an example anymore, but this perma-post somehow clings to life.

The existing AOP books go way beyond logging, but it's fair to say they haven't gone far enough. No significant examples of using AOP are yet available, reflecting a paucity of material to help typical developers begin using AOP in a systematic way.

However, we've got two new contenders: a pair of books that advance the literature to help you learn AOP. One shows, in a concrete way, what it's like to build enterprise applications using AOP. The other presents a systematic methodology for designing systems intended to be implemented with AOP.

AOP in Enterprise Java Applications

Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools (Addison-Wesley 2004), written by Adrian Colyer and other members of the AspectJ development team at IBM Hursley Park, provides a concrete walkthrough of developing applications with AOP. The book is particularly useful for developers who, after seeing smaller aspect examples, find AOP attractive but are unsure how to integrate it into their development practice.

The book's main application is a simple insurance system written using Java, AspectJ, Hibernate, JMX, Spring, JUnit and Eclipse. A number of concrete aspects arise in its development, including notification, various forms of exception handling, persistence using Hibernate, application management, business rule validation and architecture enforcement.

Eclipse AspectJ also provides a clear demonstration of the actual development of the application: setting up the file and project structure, integration of aspects and unit testing, aspect configuration management, and debugging of aspect code. If you want to see how a real AOP project works in the presence of really good IDE support, this book is a must-read.

Eclipse AspectJ also covers a number of more subtle AOP issues with discussions of what to name aspects and pointcuts, how to factor aspects and pointcuts, exploring the parallels between static and dynamic pointcuts, and overloading and overriding.

An AOP Design Methodology

Ivar Jacobson and Pan-Wei Ng's Aspect-Oriented Software Development with Use Cases (Addison-Wesley, 2004) offers a new take on use case--oriented design. The key idea? Use cases crosscut components, and aspects crosscut components, so use cases and aspects should fit hand-in-glove. The book shows how you can use aspects to preserve the modularity of use cases through different levels of design model all the way down to the code. It represents a significant proposal for a comprehensive approach to designing and implementing with aspects.

This book speaks directly to some of the most common questions about AOP: How should aspects be incorporated at the design level? How should you identify aspects?

One theme distinguishes between what Jacobson and Ng call peer use cases and extension use cases, offering insight about when to use aspects as part of a system's core functionality and when to use them as an extension mechanism. The book's methodology addresses structuring of use cases, and how that maps down to structuring aspects in the implementation.

Of course, neither of these books is perfect. AOP, AOP tools and our understanding of how to use AOP are still evolving, and we should expect that the tools, techniques and methods described in these books will improve with time. In a few years, we'll have new and improved books on these topics. But today, these books represent a real advance, and they're a must-have to help you make practical use of AOP.

Gregor Kiczales led the Xerox PARC teams that developed aspect-oriented programming and AspectJ, and is an AOP consultant and instructor 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.