Aspect-oriented programming (AOP) is a promising new paradigm that came out of Xerox PARC a few years ago and is just now becoming mature and mainstream. A natural complement to object-oriented programming, it has the promise of easing the management of complex systems and making their organization much more intuitive, extendable, and flexible. AOP makes OOP multidimensional.

What is an Aspect? An Aspect is a common functionality that's scattered across methods, classes, object hierarchies, or object models. Functionality that your class or object model shouldn't be concerned about, functionality that doesn't belong as it's not what the object is all about. The AOP-ites like to call this type of functionality crosscutting concerns, as the behavior is cutting across multiple points in your object models, and yet is distinctly different from the classes it's crosscutting. AOP allows you to abstract and seamlessly componentize these concerns and apply them to your applications in a unique way that regular object-oriented programs cannot achieve very easily.

A simple example of a crosscutting concern is timing and metrics. Let's say you wanted to add code similar to Listing 1 to your application that would measure the amount of time it would take to invoke a particular method.

There are a few problems with this approach:
1.  You have to manually add this code to multiple different files, methods, and classes, which is a pain; if you want to change which methods are profiled you have to manually edit those files. In other words, this is hard to turn off and on and difficult to maintain.
2.  The profiling code really doesn't belong sprinkled throughout your application code. It makes your code bloated and harder to read as you have to enclose the timings within a try-finally block.
3.  If you want to add other metrics like a method count or a failure count, you would have to modify all the files where you manually inserted the profiling code. It's very difficult to maintain, expand, and extend your metrics functionality as it's dispersed throughout your entire code base.

This is a tiny example of how you can have common code that is sprinkled across many unrelated modules of your application; code that intrudes on the overall purpose of the Java class you're implementing. Aspect-oriented programming provides a way to pull together these common behaviors into a manageable unit and apply them to your code base. Let's look at how AOP would implement and solve this problem.

Defining an Aspect
The first thing that should be done to aspectize the metrics functionality would be to create an Aspect. The try-finally block that we originally had within the BankAccount.withdraw method should be extracted and encapsulated into its own object. Having this code within its own object enables us to easily expand and maintain any additional metrics we may want to calculate later on in the development cycle. For this object to work, it must be able to wrap around and obtain contextual information about the particular method you want to add profiling to so that metrics can be displayed. There are a few AOP frameworks out there, so rather than picking one framework to give an example in, let's look at some pseudo code that could be easily translated into a real framework later on (see Listing 2).

The MetricsAspect class pulls together the metrics functionality into one maintainable, extendable unit. The invoke method at line 3 should be called in place of the actual method you want to provide metrics for. All AOP frameworks should provide some form of abstraction for wrapping/intercepting a method call. Line 8 wraps and delegates to the actual method. Line 13 assumes that you can obtain contextual information about the method call from the AOP framework you are using.

Applying an Aspect
Now that we have extracted out the metrics functionality into a componentized Aspect, how can we apply it? This is where a pointcut comes in. A pointcut defines an entry point within your code base. It describes an event. An entry point could be a field access, a method call, or a constructor call. An event could be an exception being thrown. A pointcut is a way for you to define where you want your aspects applied. Let's look at some pseudo XML configuration for a pointcut that any AOP framework should be able to do in some form or another.

1. <method-pointcut expr="com.mc.BankAccount.withdraw(double amount)">
2. <attach-aspectclass="com.mc.MetricsAspect"/>
3. </method-pointcut>
4. <method-pointcut expr="com.mc.billing.*">
5. <attach-aspectclass="com.mc.MetricsAspect"/>
6. </method-pointcut>

Lines 1-3 define a pointcut that applies the metrics aspect to the specific method BankAccount.withdraw. Lines 4-6 define a general pointcut to apply the metrics aspect on all methods in all classes under the com.mc. billing package name. Most AOP frameworks have a rich set of pointcut expressions that you can use to apply your aspects. You can attach your aspects on an individual one-on-one basis to each Java class in your application, or you can use a more complex pointcut to specify a wide range of classes with one expression.

What this example shows is that with AOP, you're able to pull together crosscutting behavior into one object and sprinkle it easily and simply throughout your code base without making code unreadable or polluted with functionality that doesn't belong with the business logic you are implementing. Common crosscutting functionality can be maintained and extended in one place.

Another thing to notice is that the code within the BankAccount class has no idea that it's being profiled. The application developer was allowed to focus on writing business logic rather than being distracted with writing the code candy and syntactic sugar of profiling. Needed orthogonal behavior could be snapped on after the fact quite easily without even touching this existing code base. This is a very subtle significant part of AOP as this complete obliviousness allows aspects to be layered on top of or below the functionality they are crosscutting. A layered design allows you, as a system designer, to more easily snap on or remove functionality or behavior that you need. For instance, maybe you only snap on the metrics functionality when you're doing some benchmarks but want to remove this within production. Or, if the AOP framework allows for it, maybe you want to turn on metrics in production to determine where bottlenecks are.

Real-World AOP
In the early days of object-oriented programming, it was user-interface applications that helped to scope and discover object-oriented patterns and techniques. If you look at the Gang of Four's Design Patterns book (the bible of object-oriented programming), you'll see that GUIs are used in many of the coding examples that describe the patterns in the book. As GUIs helped formulate the early patterns of OO, middleware is shaping up to be the killer app for aspect-oriented programming.

Middleware, by nature, is crosscutting. It has functionality that's common across object hierarchies that really should not be mingled with business logic. The evolution of middleware has always been to abstract out how it is applied to regular simple objects. AOP completes this evolution as middleware functionality can be applied after the fact without changing the code or design of the existing business model. Packaging up middleware into a set of aspects frees developers to focus on writing the plain Java objects that make up their application's specific behavior rather than forcing them to work under an API dictated to them by their system architecture.

Take J2EE, for instance. It can be sliced and diced and served à la carte to your object model rather than going through the sometimes cumbersome and unnecessary process of implementing an EJB. For instance, let's say you were using EJB solely for the purpose of defining transactions. Transaction demarcation lines could be drawn within any class at any point using AOP. Instead of extending SessionBean and writing home, remote, and local interfaces; deciding on a JNDI binding; and defining all your <ejb-ref>s in XML; all you would have to do is define a pointcut for the method of the class you want a transaction started from and attach the transactional aspect to trigger the desired behavior.

1. <method-pointcut expr="com.mc.BankAccount.withdraw(double amount)">
2. <attach-aspect class="org.vendor.transaction.RequiredAspect"/>
3. </method-pointcut>

You can apply these same techniques to a multitude of middleware technology like remoteness, ACID, replicated caching, oneway, simple asynchronous invocations, role-based security, and persistence. AOP prevents system programming from intruding into your object model. It has the potential to completely separate the concern of middleware from your application logic. This can make your code easier to maintain and read, and more flexible as you can make system architecture decisions later on in the development process. It's a pure layered approach to applying middleware.

Conclusion
AOP is a new paradigm for expanding code reuse and easing the maintainability of your code base. It provides mechanisms to easily componentize code that is scattered throughout your object model and really needs to be organized centrally into one set of objects. When combined with something like middleware, it has the ability to isolate your business logic from the confines of system architecture, thus making your applications even more resistant to change as the landscape of APIs and public specifications changes over time. As framework developers focus on providing their functionality through aspects, the term pointcut will be morphed into pointclick as aspects are applied to an object model through the point-and-click interfaces of an IDE.