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:
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.
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:
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.