Discovering AOP

This chapter covers
■ Understanding crosscutting concerns
■ Modularizing crosscutting concerns using AOP
■ Understanding AOP languages

Reflect back on your last project, and compare it with a project you worked on a few
years back. What’s the difference? One word: complexity. Today’s software systems are
complex, and all indications point to even faster growth in software complexity in
the coming years. What can a software developer do to manage complexity?
If complexity is the problem, modularization is the solution. By breaking the
problem into more manageable pieces, you have a better shot at implementing
each piece. When you’re faced with complex software requirements, you’re likely
to break those into multiple parts such as business functionality, data access, and
presentation logic. We call each of these functionalities concerns of the system. In a
banking system, you may be concerned with customer management, account management, and loan management. You may also have an implementation of data
access and the web layer. We call these core concerns because they form the core
functionality of the system. Other concerns, such as security, logging, resource
pooling, caching, performance monitoring, concurrency control, and transaction
management, cut across—or crosscut—many other modules. We call these functionalities crosscutting concerns.
For core concerns, object-oriented programming (OOP), the dominant methodology employed today, does a good job. You can immediately see a class such as
LoanManagementService implementing business logic and AccountRepository implementing data access. But what about crosscutting concerns? Wouldn’t it be nice if you
could implement a module that you identify as Security, Auditing, or PerformanceMonitor? You can’t do that with OOP alone. Instead, OOP forces you to fuse the implementation of these functionalities in many modules. This is where aspect-oriented
programming (AOP) helps.
AOP is a methodology that provides separation of crosscutting concerns by introducing a new unit of modularization—an aspect. Each aspect focuses on a specific
crosscutting functionality. The core classes are no longer burdened with crosscutting
concerns. An aspect weaver composes the final system by combining the core classes
and crosscutting aspects through a process called weaving. Thus, AOP helps to create
applications that are easier to design, implement, and maintain.
In this chapter, we’ll examine the fundamentals of AOP, the problems it addresses,
and why you need to know about it. In the rest of the book, we’ll examine AspectJ,
which is a specific implementation of AOP. Let’s start by discussing how you manage
various concerns without AOP, which will help you understand why you need AOP.

1.1 Life without AOP

How do you implement crosscutting concerns using OOP alone? Typically, you add the
code needed for each crosscutting concern in each module, as shown in figure 1.1.
This figure shows how different modules in a system implement both core concerns and crosscutting concerns. Let’s illustrate the same idea through a code snippet.
Consider the skeleton implementation of a representative class that encapsulates
some business logic in a conventional way, shown in listing 1.1. A system consists of
many such classes.


Although the details will vary, the listing shows a common problem many developers
face: a conceptual separation exists between multiple concerns at design time, but
implementation tangles them together. Such an implementation also breaks the Single
Responsibility Principle (SRP)1
by making the class responsible for implementing core
and crosscutting concerns. If you need to change the invocation of the code related to
crosscutting concerns, you must change each class that includes such an invocation.
Doing so breaks the Open/Close principle2
—open for extension, but closed for modifications. The overall consequence is a higher cost of implementing features and fixing bugs.
With conventional implementations, core and crosscutting concerns are tangled in
each module. Furthermore, each crosscutting concern is scattered in many modules.
The presence of code tangling and code scattering is a tell-tale sign of the conventional implementation of crosscutting concerns.3
Let’s examine them in detail.

1.1.1 Code tangling

Code tangling is caused when a module is implemented to handle multiple concerns
simultaneously. Developers often consider concerns such as business logic, performance, synchronization, logging, security, and so forth when implementing a module.

This leads to the simultaneous presence of elements from each concern’s implementation and results in code tangling. Figure 1.2 illustrates code tangling in a module.
Another way to look at code tangling is to use the notion of a multidimensional
concern space. Imagine that you’re projecting the application requirements onto a
multidimensional concern space, with each concern forming a dimension. Here, all
the concerns are mutually independent and therefore can evolve without affecting
the rest. For example, changing the security requirement from one kind of authorization scheme to another shouldn’t affect the business logic. But as you see in figure 1.3,
a multidimensional concern space collapses into a one-dimensional implementation space.
Because the implementation space is one-dimensional, its focus is usually the
implementation of the core concern that takes the role of the dominant dimension; other concerns then tangle the core concern. Although you may naturally separate the individual requirements into mutually independent concerns during the
design phase, OOP alone doesn’t let you retain the separation in the implementation phase.
We’ve looked at the first symptom of crosscutting concerns when implemented
using traditional techniques; now, let’s move on to the next.

1.1.1 Code scattering

Code scattering is caused when a single functionality is implemented in multiple modules. Because crosscutting concerns, by definition, are spread over many modules,
related implementations are also scattered over all those modules. For example, in a
system using a database, performance concerns may affect all the modules accessing
the database.
Figure 1.4 shows how a banking system implements security using conventional
techniques. Even when using a well-designed security module that offers an abstract
API and hides the details, each client—the accounting module, the ATM module, and
the database module—still needs the code to invoke the security API to check permission. The code for checking permission is scattered across multiple modules, and
there is no single place to identify the concern. The overall effect is an undesired tangling between the modules to be secured and the security module.

Code tangling and code scattering together impact software design and development
in many ways: poor traceability, lower productivity, lower code reuse, poor quality, and
difficult evolution. All of these problems lead us to search for better approaches to
architecture, design, and implementation. Aspect-oriented programming is one viable
solution. In the next section, we’ll introduce you to AOP. Later in this chapter, we’ll
examine alternatives to AOP as well.

1.2 Modularizing with AOP

In OOP, the core concerns can be loosely coupled through interfaces, but there is no
easy way to do the same for crosscutting concerns. This is because a concern is implemented in two parts: the server-side piece and the client-side piece. OOP modularizes
the server part quite well in classes and interfaces. But when the concern is of a crosscutting nature, the client part (consisting of the requests to the server) is spread over
all the clients.

NOTE：We use the terms server and client here in the classic OOP sense to mean the
objects that are providing a certain set of services and the objects using
those services. Don’t confuse them with networking servers and clients.

As an example, let’s take another look at the typical implementation of a crosscutting
concern in OOP, shown in figure 1.4. The security module provides its services
through an interface. The use of an interface loosens the coupling between the clients and the implementations of the interface. Clients that use the security services
through the interface are oblivious to the exact implementation they’re using; any
changes to the implementation don’t require changes to the clients themselves. Likewise, replacing one security implementation with another is just a matter of instantiating the right kind of implementation. The result is that you can replace one security
implementation with another with little or no change to the individual client modules. But this arrangement still requires that each client have the embedded code to
call the API. Such calls must be included in all the modules requiring security and are
tangled with their core logic.
Using AOP, none of the core modules contain calls to the security API. Figure 1.5
shows the AOP implementation of the same security functionality shown in figure 1.4.
The security concern—implementation and invocations—now resides entirely inside
the security module and the security aspect. For now, don’t worry about the way in
which AOP achieves this; we’ll explain in the next section.
The fundamental change that AOP brings is the preservation of the mutual independence of the individual concerns. Implementations can be easily mapped back to
the corresponding concerns, resulting in a system that is simpler to understand, easier
to implement, and more adaptable to changes.

1.3 Anatomy of an AOP language

The AOP methodology is just that—a methodology. In order to be of any use in the
real world, it must be implemented, or realized. Each realization of AOP involves specifying a language or a framework and associated tools. Like any other programming
methodology, an AOP implementation consists of two parts:
■ The language specification describes the language constructs and syntax to
express implementation of the core and crosscutting concerns.
■ The language implementation verifies the code’s adherence to the language specification and translates the code into an executable form.

1.3.1 The AOP language specification

Any implementation of AOP must specify a language to implement the individual
concerns and a language to implement the weaving rules. Note that an AOP system
may offer a homogeneous language that doesn’t distinguish between the two parts.
This is likely to be the case in future AOP languages. Let’s take a closer look at these
two parts.
IMPLEMENTATION OF CONCERNS
As in other methodologies, the concerns of a system are implemented into modules
that contain the data and behavior needed to provide their services. A module that
implements the core part of the caching concern maintains a collection of cached
objects, manages the validity of the cached objects, and ensures bounded memory
consumption. To implement both the core and crosscutting concerns, we normally
use standard languages such as C, C++, and Java.
WEAVING RULES SPECIFICATION
Weaving rules specify how to combine the implemented concerns in order to form the
final system. After you implement the core part of the caching concern in a module
(perhaps through a third-party class library), you must introduce caching into the system. The weaving rule in this case specifies the data that needs to be cached, the information that forms the key into the cache storage, and so forth. The system then uses
these rules to obtain and update cache from the specified operations.
The power of AOP comes from the economical way of expressing the weaving
rules. For instance, to modularize tracing concerns in listing 1.1, you can add a few
lines of code to specify that all the public operations in the system should be logged.
Here is a weaving specification for the tracing aspect:
■ Rule 1: Create a logger object.
■ Rule 2: Log the beginning of each public operation.
■ Rule 3: Log the completion of each public operation.
This is much more succinct than modifying each public operation to add logging
code. Because the tracing concern is modularized away from the class, it may focus
only on the core concern, as follows:

Compare this class with the one in listing 1.1: all the code to perform tracing—the
ancillary concerns from the class’s point of view—have been removed. When you
apply the same process to other crosscutting concerns, only the core business logic
remains in the class. As you’ll see in the next section, an AOP implementation combines the classes and aspects to produce a woven executable.
Weaving rules can be general or specific in the ways they interact with the core
modules. In the previous logging example, the weaving rules don’t need to mention
any specific classes or methods in the system. On the other end of the spectrum, a
weaving rule may specify that a business rule should be applied only to specific methods, such as the credit() and debit() operations in the Account class or the ones
that carry the @ReadOnly annotation. The specificity of the weaving rules determines
the level of coupling between the aspect and core logic.
The language used to specify weaving rules can be a natural extension of that language or something entirely different. For example, an AOP implementation using Java
as the base language might introduce new extensions that blend well with the base language, or it could use a separate XML-based language to express weaving rules.

1.3.2 The AOP language implementation

The AOP language implementation performs two logical steps: It first combines the
individual concerns using the weaving rules, and then it converts the resulting information into executable code. AOP implementation thus requires the use of a processor—weaver—to perform these steps.
An AOP system can implement the weaver in various ways. A simple approach uses
source-to-source translation. Here, the weaver processes source code for individual
classes and aspects to produce woven source code. The aspect compiler then feeds
this woven code to the base language compiler to produce the final executable code.
This was the implementation technique used in early implementations of AspectJ.
The approach suffers from several drawbacks because the executable code can’t be
easily traced back to the original source code. For example, stack traces indicate line
numbers in woven source code.
Another approach first compiles the source code using the base language compiler. Then, the resulting files are fed to the aspect compiler, which weaves those files.
Figure 1.6 shows a schematic of a compiler-based AOP language implementation.
An AOP system may also be able to push the weaving process close to execution of
the system. If the implementation of AOP is Java-based, a special class loader or a virtual

machine (VM) agent can perform the weaving. Such an implementation first loads the
byte code for the aspects, weaves them into the classes as they’re being loaded, and supplies those woven versions of the classes to the underlying VM.
Yet another implementation could use automatically created proxies. In this case,
each object that needs weaving is wrapped inside a proxy. Such an implementation
typically works well in conjunction with another framework that controls the creation
of objects. In this way, the framework can wrap each created object in a proxy.
So far, we’ve looked at the mechanics of an AOP system. Now, let’s examine AOP’s
fundamental concepts.

1.4 Fundamental concepts in AOP

By now, it should be clear that AOP systems help in modularizing crosscutting concerns. But so do many other technologies, such as byte-code manipulation tools,
direct use of the proxy design pattern, and meta-programming. How do you differentiate AOP from these options? To find out, we need to distill the core characteristics of
AOP systems into a generic model. If a system fits that model, it’s an AOP system.
To implement a crosscutting concern, an AOP system may include many of the following concepts:
■ Identifiable points in the execution of the system —The system exposes points during
the execution of the system. These may include execution of methods, creation
of objects, or throwing of exceptions. Such identifiable points in the system are
called join points. Note that join points are present in all systems—even those
that don’t use AOP—because they’re points during execution of a system. AOP
merely identifies and categorizes these points.
■ A construct for selecting join points —Implementing a crosscutting concern
requires selecting a specific set of join points. For example, the tracing aspect
discussed earlier needs to select only the public methods in the system. The
pointcut construct selects any join point that satisfies the criteria. This is similar
to an SQL query selecting rows in database (we’ll compare AOP with databases
in section 1.5.2). A pointcut may use another pointcut to form a complex selection. Pointcuts also collect context at the selected points. For example, a pointcut may collect method arguments as context. The concept of join points and
the pointcut construct together form an AOP system’s join point model. We’ll
study AspectJ’s join point model in chapter 3.
■ A construct to alter program behavior —After a pointcut selects join points, you
must augment those join points with additional or alternative behavior. The
advice construct in AOP provides a facility to do so. An advice adds behavior
before, after, or around the selected join points. Before advice executes before
the join point, whereas after advice executes after it. Around advice surrounds
the join point execution and may execute it zero or more times. Advice is a
form of dynamic crosscutting because it affects the execution of the system. We’ll
study AspectJ’s dynamic crosscutting implementation in chapter 4.
■ Constructs to alter static structure of the system —Sometimes, to implement crosscutting functionality effectively, you must alter the static structure of the system.
For example, when implementing tracing, you may need to introduce the logger field into each traced class; inter-type declaration constructs make such modifications possible. In some situations, you may need to detect certain conditions,
typically the existence of particular join points, before the execution of the system; weave-time declaration constructs allow such possibilities. Collectively, all
these mechanisms are referred to as static crosscutting, given their effect on the
static structure, as opposed to dynamic behavior changes to the execution of
the system. We’ll study AspectJ’s static crosscutting support in chapter 5.
■ A module to express all crosscutting constructs —Because the end goal of AOP is to
have a module that embeds crosscutting logic, you need a place to express that
logic. The aspect construct provides such a place. An aspect contains pointcuts,
advice, and static crosscutting constructs. It may be related to other aspects in a
similar way to how a class relates to other classes. Aspects become a part of the
system and use the system (for example, classes in it) to get their work done.
We’ll examine AspectJ’s implementation of aspect in chapter 6.
Figure 1.7 shows all these players and their relationships to each other in an AOP system.
Each AOP system may implement a subset of the model. For example, Spring AOP
(discussed in chapter 9) doesn’t implement weave-time declarations due to its emphasis on its runtime nature. On the other hand, the join point model is so central to
AOP that every AOP system must support it—everything else revolves around the joinpoint model.
When you encounter a solution that modularizes crosscutting concerns, try to map
it onto the generic AOP model. If you can, then that solution is indeed an AOP system.
Otherwise, it’s an alternative approach for solving the problem of crosscutting concerns.

1.5 AOP by analogy

When you’re learning a new technology, it sometimes helps to compare it with existing technologies. In this section, we’ll attempt to help you understand AOP by
comparing it with Cascading Style Sheets (CSS), database programming, and eventoriented systems. The purpose of this section is to help those familiar with at least one
of these technologies to understand AOP by analogy.

1.5.1 Cascading Style Sheets (CSS)

CSS is a widely supported mechanism to separate content from presentation in HTML
pages. Without CSS, formatting information is fused with content (causing tangling),
and similar content elements have presentational information spread into multiple
places (causing scattering). CSS helps the situation by letting the main document focus
on content by separating the formatting information into a document called a stylesheet.
A core concept in CSS is a selector that selects document elements matching a certain specification. For example, the body p selector can select paragraphs inside the
body element. You can then associate presentational information with a selector and,
for example, set the background color of such elements to blue using the body p
{background: blue;} element.
AOP acts on classes in the same way that CSS acts on documents. AOP lets you separate crosscutting logic from the main-line logic. AOP’s pointcuts have the same selection role as CSS selectors. Whereas CSS selectors select structural elements in a
document, pointcuts select program elements. Similarly, the blocks describing the formatting information are analogous to AOP advice in functionality.
Often, the selection mechanism requires more information than merely using the
inherent characteristics of a structure such as body p. It’s common practice to supplement content elements with additional metadata through the class attribute. For
example, you can mark an HTML paragraph element as menu by using the tag

. Then, in the stylesheet, you can select such an element by using the
p.menu selector and apply appropriate presentation characteristics. In AOP, practitioners face the same problem—selection through a pointcut often requires information
beyond merely relying on inherent characteristics of the program elements such as
class and method names. The use of Java annotations plays a role similar to the class
attribute in HTML documents. You can, for example, mark a method as @Transactional and utilize it in a pointcut expression.
There are similarities from the adoption perspective as well. Through WYSIWYG
HTML editors, it’s easy to create a good-looking HTML. That apparent simplicity led to
many initial web documents embedded with formatting information. But when we
realized that it’s difficult to create a consistent look when every element’s formatting
is specified independently, developers started to look favorably at CSS. AOP has
encountered a similar trend. There is a level of comfort in embedding the implementation of crosscutting functionality inside classes; you can see exactly what’s going to
happen. But you soon realize that creating a consistent implementation is nearly
impossible when similar code is scattered in many places. In addition, using CSS
requires a level of expertise and understanding of the semantics associated with the
elements in a document. Using AOP requires similar understanding of the semantic
separation between core and crosscutting elements.
CSS works at the structure level, and database triggers offer similar separation at
the programming level. Let’s see how that technique compares with AOP.

1.5.2 Database systems

Database systems offer “dynamic crosscutting” targeted toward data access, whereas
AOP offers a similar mechanism toward general programming. It offers two good analogies to AOP concepts: SQL with pointcuts and triggers with advice.
SQL AND POINTCUTS
A join point is like a row in a database, whereas a pointcut is like an SQL query. An SQL
query selects rows according to a specified criterion such as “rows in accounts table,
where the balance is greater than 50”. It provides access to the content of the selected
rows. Similarly, a pointcut is a query over program execution that selects join points
according to a specified criterion such as “method execution in the Account class,
where the method name starts with ‘set’”. It also provides access to the join point context (objects available at the join point, such as method arguments).
TRIGGERS AND ADVICE
Database programming often uses triggers to respond to changes made in data. For
example, you can use a trigger to audit changes in certain tables. The following snippet calls the logInventoryIncrease() procedure when inventory increases:

The static condition, such as the name of the table and the modified column, as well
as the dynamic condition, such as the difference in the column value, are analogous
to AOP’s pointcut concept. Both describe a selection criterion to “trigger” certain
actions. The stored procedure specified in the trigger is analogous to AOP’s advice.
Database triggers and AOP’s advice both modify the normal program execution to
carry additional or alternative actions. But there are some obvious differences. Database triggers are useful only for database operations. AOP has a more general
approach that can be used for many other purposes. But note that AOP doesn’t necessarily obviate the need for database triggers, for reasons such as performance and
bringing uniformity to multiple applications accessing the same tables.
Similar to database triggers, event-oriented programming includes the notion of
responding to events.

1.5.3 Event-oriented programming

Event-oriented programming is essentially the observer design pattern (we’ll discuss it
as an alternative to AOP in section 1.7.3). Each interested code site notifies the observers by firing events, and the observers respond by taking appropriate action, which
may be crosscutting in nature.
In AOP, the program is woven with logic to fire virtual events and to respond to the
events with an action that corresponds to the crosscutting concern it’s implementing.
But note this important difference: Unlike in event-based programming, there is no
explicit code for the creation and firing of events in the subject classes. Executing part
of the program constitutes the virtual-event generation. Also, event systems tend to be
more coarse-grained than an AOP solution implements.
Note that you can effectively combine event-oriented programming with AOP. Essentially, you can modularize the crosscutting concern of firing events into an aspect. With
such an implementation, you avoid tangling the core code with the event-firing logic.
Now that you have a good understanding of AOP, let’s turn our attention to a bit of
history and the current status of AOP implementations.