Aspect orientation is a set of technologies aimed at providing better separation of crosscutting concerns. It is sometimes also known as advanced separation of concerns. Research in aspect orientation has been going on for a relatively long time, but it started gaining a lot of recognition from mainstream observers in 1997 when Gregor Kiczales from Xerox Parc presented his keynote presentation on aspect-oriented programming (AOP) at OOPSLA ’97. AOP, and specifically, AspectJ, is the most popular aspect technology [Kiczales et al. 1997] [Kiczales et al. 2000]. AspectJ is an extension to the Java language with new constructs to separate and modularize concerns:

AOP is not the only technique that deals with crosscutting concerns. A number of works from the research community, such as the following, address the issue:

Furthermore, AOP is not just AspectJ. Other AOP implementations include AspectWerkz and JBoss-AOP. You might wish to take a look at these evolving technologies. Although we show some code samples for AspectJ, AOP has also been implemented in languages like C, C++, and C#. The truth of the matter is that the idea of keeping concerns separate pervades throughout all software development and is not limited to object-oriented systems alone.

In Chapter 1, “Problem to Attack,” we highlighted two specific kinds of crosscutting concerns that you need to keep separate—peers and extensions. Through some code samples in AspectJ, we show you how the above constructs help you keep such crosscutting concerns separate. Our intent is to show how you keep concerns separate, not to explain the details of AOP or AspectJ, so our examples are significantly simplified. As a developer, you might want to learn the specifics of AOP and AspectJ. The downloads along with additional code samples and a description of the AspectJ language extension to Java are available at the AspectJ Web site: http://www.eclipse.org/aspectj.

As a quick recap, peer concerns are distinct from each other, but their realizations overlap classes. Let’s consider the example of a Hotel Management System, which we use throughout the book. In particular, we discuss three specific functionalities in this example system: room reservation, customer check-in, and customer check-out. Briefly, the functionalities are as follows:

Figure 2-1 shows how these functionalities (represented horizontally) cut across classes in the system (shown as boxes). Each box lists the operations imposed on the respective classes.

Figure 2-1. Classes composed from different concerns.

Note that there are other operations not shown in Figure 2-1 that are common across the different functionalities. These operations are reusable, but our emphasis in Figure 2-1 is that the various functionalities impose different operations on the respective classes. As a developer, you need to collect all these responsibilities to implement each class. This is where crosscutting and, hence, tangling occurs. The Room class contains code needed by different peer functionalities. With AOP intertype declarations, you can indeed keep the specifics of each peer concern separate. Simplified Source Code to Check In Customer 0-1 shows the simplified listing that implements the Check In Customer functionality as an aspect using AspectJ.

1.  public aspect CheckInCustomer {
2.    ...
3.    public void Room.assignCustomer ()
4.    {
5.      // code to check in customer
6.    }
7.    public void Reservation.consume()
8.    {
9.      // code to consume reservation
10.   }
11.   public void Payment.createBill()
12.   {
13.     // code to generate an initial outstanding bill
14.   }
15.   ...
16. }

Line 1 in Listing 2-1 declares CheckInCustomer as an aspect, as indicated by the aspect keyword. It contains a series of intertype declarations. There are two segments of an intertype declaration we want to highlight. The first segment is the name of an existing class, and the second segment is the existing operation that you want to add into. So, for instance, in line 3, you see

Room.assignCustomer()

This adds the operation assignCustomer() into the Room class. Notice that although this operation is part of the Room class, it is defined outside the Room class itself. Thus, aspect orientation escapes from the restriction on a class property needing to be defined within the traditional class modularity. This allows us alternate ways of organizing code—one that keeps the realization of peer concerns separate.

Let us now look at how AOP can help you keep extensions separate. Extensions are add-ons to some base behavior. In this case, we have a base reserve room functionality, which we want to extend. Figure 2-2 shows a state chart describing the steps within a makeReservation operation. A user wants to make a reservation for a room from a certain date to a certain date. If there are no rooms available, the system displays a message indicating there are no rooms. If rooms are available, the system creates a reservation.

Figure 2-2. makeReservation operation.

Suppose that you want additional functionalities (i.e., extensions) specifically to ensure that only authorized users are permitted to make a room reservation, and if there are no Rooms available, you want to put the user on a waiting list. This can be achieved in two steps:

The extension points where you need to add or modify are marked as and for the authorization check and waiting list functionality, respectively. After composing the extension into the existing operation, you have the result in Figure 2-3. The shaded areas represent where updates have been made.

Figure 2-3. makeReservation modified with authorization and waiting list.

As shown in Figure 2-3, the additional behavior to check for authorization has been composed into the existing operation at marker . At marker , instead of displaying a message indicating there are no rooms, the customer is put in a queue.

As you can see in Figure 2-3, the original makeReservation operation is now entangled with code needed to fulfill requirements not directly related to making reservations. Worse, it makes the makeReservation operation less understandable for the developer. But Figure 2-3 does represent the final composed behavior you want. If you want to analyze the performance over all other runtime characteristics, you must analyze the composed result, but you normally do so with a perspective that treats functionality generically. We discuss this issue in Part 4 of the book.

We now illustrate how AspectJ can be applied to keep the waiting list and authorization extensions separate. Listing 2-2 shows the code fragment for the reserve room functionality implemented in a class named ReserveRoomHandler.

1.  class ReserveRoomHandler {
2.    ...
3.    public void makeReservation() throws NoRoomException
4.    {
5.      if(theRoom.getQuantityAvailable()<=0) {
6.          throw new NoRoomException () ;
7.      }
8.      createReservation() ;
9.    }
10.   ...
11. }

The ReserveRoomHandler class has an operation called makeReservation(), which as the name implies performs the reservation. It throws a NoRoomException if no rooms are available. The makeReservation() operation makes two calls:

We look at how aspects in AOP help us keep the waiting list and the authorization extensions separate.

1.  aspect HandleWaitingList {
2.    ...
3.    pointcut makingReservation() :
4.        execution(void ReserveRoomHandler.makeReservation()) ;
5.    ...
6.    after throwing (NoRoomException e) : makingReservation() {
7.      // code to add customer to waiting list ;
8.    }
9.  }

1.  aspect HandleAuthorization {
2.    pointcut performingTransaction ():
3.             call(void ReserveRoomHandler.*(..))
4.             || call(void CheckInHandler.*(..));
5.    void around () : performingTransaction() {
6.       if(isAuthorized()) {
7.          proceed() ;
8.       }
9.    }
10. }

The composition mechanism in AOP gives you the ability to define behavior from outside a class. This is something relatively new to most of you. But a word of caution: we do not want you to be trigger-happy and poke advices into existing operations or add intertype declarations to existing classes in an uncontrolled manner. If you do so, you will end up with a patchwork system that is impossible to extend.

AOP provides a powerful composition mechanism for a reason: so you can achieve better separation of concerns and better modularity. Thus, you have to think about design and about when you should code behaviors into classes or aspects. To apply aspect orientation effectively, therefore, you need to know how to systematically identify aspects and classes. More accurately, the question should be how you identify concerns from which aspects and classes are derived.

In addition, keeping concerns separate does not mean that concerns are independent. For example, it is clear that waiting list functionality has dependencies on the room reservation functionality. This means that if the requirements for the latter changes, the former may also be impacted. You must be able to model concerns and their relationships. In this way you get a better understanding of stakeholder concerns and consequently can separate them better. The use-case technique provides such a method for you to model concerns and relationships, and the use-case–driven approach will help you drive the concerns all the way down to implementation.