I want my AOP!, Part 1

Separate software concerns with aspect-oriented programming

By Ramnivas Laddad, JavaWorld.com, 01/18/02

Page 2 of 7

Currently, OOP serves as the methodology of choice for most new software development projects. Indeed, OOP has shown its strength when it comes to modeling common behavior. However, as we will see shortly, and as you may have already experienced, OOP does not adequately address behaviors that span over many -- often unrelated -- modules. In contrast, AOP methodology fills this void. AOP quite possibly represents the next big step in the evolution of programming methodologies.

View the system as a set of concerns

We can view a complex software system as a combined implementation of multiple concerns. A typical system may consist of several kinds of concerns, including business logic, performance, data persistence, logging and debugging, authentication, security, multithread safety, error checking, and so on. You'll also encounter development-process concerns, such as comprehensibility, maintainability, traceability, and evolution ease . Figure 1 illustrates a system as a set of concerns implemented by various modules.

Figure 2 presents a set of requirements as a light beam passing through a prism. We pass a requirements light beam through a concern-identifier prism, which separates each concern. The same view also extends towards development-process concerns.

Crosscutting concerns in a system

A developer creates a system as a response to multiple requirements. We can broadly classify these requirements as core module-level requirements and system-level requirements. Many system-level requirements tend to be orthogonal (mutually independent) to each other and to the module-level requirements. System-level requirements also tend to crosscut many core modules. For example, a typical enterprise application comprises crosscutting concerns such as authentication, logging, resource pooling, administration, performance, and storage management. Each crosscuts several subsystems. For example, a storage-management concern affects every stateful business object.

Let's consider a simple, but more concrete, example. Consider a skeleton implementation of a class encapsulating some business logic:

public class SomeBusinessClass extends OtherBusinessClass {
    // Core data members
    // Other data members: Log stream, data-consistency flag
    // Override methods in the base class
    public void performSomeOperation(OperationInformation info) {
        // Ensure authentication
        // Ensure info satisfies contracts
        // Lock the object to ensure data-consistency in case other 
        // threads access it
        // Ensure the cache is up to date
        // Log the start of operation
        // ==== Perform the core operation ====
        // Log the completion of operation
        // Unlock the object
    }
    // More operations similar to above
    public void save(PersitanceStorage ps) {
    }
    public void load(PersitanceStorage ps) {
    }
}

In the code above, we must consider at least three issues. First, other data members do not belong to this class's core concern. Second, implementation of performSomeOperation() seems to do more than perform the core operation; it seems to handle the peripheral logging, authentication, multithread safety, contract validation, and cache management concerns. In addition, many of these peripheral concerns would likewise apply to other classes. Third, it is not clear if save() and load() performing persistence management should form the core part of the class.