AOP Explained

The primary goal of the AOP paradigm is to provide a mechanism for modularizing crosscutting concerns. The creators of AOP wanted a programming approach that could abstract and encapsulate crosscutting concerns, thereby facilitating software reuse.

Through the modularization of crosscutting concerns, AOP makes it possible to avoid code scattering and code tangling. Moreover, AOP implementations go beyond this primary goal and bring a dynamic element to the static nature of object-oriented applications. The static model of OOP designs is sensitive to change, with a change in requirements having the potential to wreak havoc upon the conventional static model. As we shall see, the dynamic capabilities of AOP implementations are of significant interest for rapid development because they offer the flexibility to accommodate change within the system.

To understand AOP, we must understand the concepts and terminology the paradigm introduces to the software engineering discipline.

Concepts and Terminology

OOP adds numerous new terms to the software engineer's vocabulary, such as inheritance, composition, overloading, overriding, and everyone's favoritepolymorphism. Learning the practices of OOP requires familiarity with these alien concepts.

Like OOP, AOP also comes complete with its own nomenclature, requiring our vocabulary to expand once again to encompass the paradigm's concepts of crosscutting concerns, join points, pointcuts, advice, aspects, and weaving.

Here is an explanation of the AOP terminology:

Join points.

A join point represents the point at which a crosscutting concern intersects with a main concern. Join points are well-defined locations in a program's execution path, and examples include method invocation, conditional statements, and object instantiation. Essentially, a join point can be any point in an application's execution.

Pointcuts.

If a join point is a well-defined point in an application's execution, then a pointcut is a language construct that identifies specific join points within the program. A pointcut defines a collection of join points, with a pointcut designator picking out specific join points and values at these points. The pointcut also provides a context for the join point.

Advice.

Advice is the code executed upon reaching a particular pointcut within the program. Advice is therefore an implementation of a crosscutting concern.

Aspects.

Aspects encapsulate join points, pointcuts, and advice into a unit of modularity for crosscutting concerns and offer reuse mechanisms for crosscutting concerns equivalent to that of a Java class for core concerns.

Weaving.

Having separated the different concerns, to complete the system, it is necessary to recombine them to form the executing program. This process of interleaving aspects with the main application is known as weaving. The AOP weaver composes the different implementation aspects into a cohesive system in accordance with specific weaving rules.

AOP is therefore a process of weaving aspects that define crosscutting concerns into an application implemented in a conventional language that defines the core concerns. The result of the weaving process is a combination of concern types that make up the final system.

Classes and aspects are independent of one another, with only the pointcut declaration serving to bind the two paradigms. Classes are therefore unaware of the presence of aspects, and this is an important AOP concept.

This relationship between aspects and classes is very well described in an excellent early paper on AOP, Aspect-Oriented Programming: A Critical Analysis of a New Programming Paradigm [Highley, 1999]. The paper's authors illustrate the relationship between OOP classes and AOP aspects by describing a mythical world inhabited by hunchbacks and dragons.

Hunchbacks and Dragons

Taken from the paper, the hunchbacks of the mythical world all worked in houses with glass ceilings. Dragons flew around the skies, observing the behavior of the hunchbacks in the houses below. The hunchbacks couldn't look up and so were unaware of the existence of the dragons.

The hunchbacks communicated with hunchbacks in other houses by sending each other mail. The mail they received from other hunchbacks helped direct the work they completed for the day. The dragons, being inquisitive creatures, kept a close eye on the hunchbacks, including reading the hunchbacks' mailhowever, the dragons never stole or interfered with the mail.

At a given point, the dragons would suddenly leap into action. They might, for example, paint one of the houses red. The hunchbacks would notice their house had magically changed color, but they wouldn't do anything about it. They would continue with their everyday tasks, still oblivious to the existence of the dragons.

This allegory perfectly captures the relationship between classes and aspects. From the story, the classes relate to the hunchbacks while the flying dragons represent aspects. An OOP application is self-contained, but aspects allow the augmentation of the application's behavior without the need to change the underlying static object model. Aspects therefore offer the ability to inject new behavior into an existing system dynamically and transparently.

The task of mixing the two worlds of OOP and AOP is achieved using a weaver.

Weaving Methods

The process of weaving is critical to AOP. As the AOP paradigm has evolved, various approaches to the process of weaving have emerged. The following lists the different methods for injecting advice into a Java application:

Compile-time.

This approach produces a woven application during the stages of the compilation process. First, aspects and classes are compiled to standard Java bytecode. Weaving then takes place as a postcompilation step using bytecode manipulation to add advice at the designated join points within the program.

Load-time.

Load-time weaving defers the weaving process until the application is in a running state. Weaving then occurs at the bytecode level at class-load time. This method is known as code injection.

Runtime.

Here, the process is similar to that of load-time weaving, except weaving at the bytecode level occurs as join points are reached in the executing application. This approach is also known as interception or call-time weaving.

Load-time and runtime weaving methods have the advantage of being highly dynamic, enabling on-the-fly changes to a running system. On the downside, such changes can adversely affect system stability and performance. In contrast, compile-time weaving offers superior performance, but requires the rebuilding and deployment of the application in order to effect a change.

Having set the scene, it is now time to go over an AOP example to illustrate how the various AOP concepts are applied. We first look at an example of AOP using AspectJ, an AOP language implementation, and then compare it to AspectWerkz, a framework for adding aspects to Java applications.