14.1. ASPECTS AND TRANSFORMATION
The impetus for aspect-oriented programming is that in other coding paradigms, the code that implements some features can be scattered across the body of the program, tangled in with code that implements other features. This occurs in features such as logging, caching, and security, where often code of a similar form is invoked many times throughout the program. This code has many disadvantages: It is tedious to write, it is error-prone, it complicates the program, and the calls can add overhead that may be needless for many users.
By inserting these calls automatically, transformation lifts the burden from the programmer and reduces the number of potential errors. This technique gains even more weight when the inserted code is a more complex series of operations that may change at some later point; centralizing the point of programming allows quicker development and enables a higher degree of reuse. However, the task of inserting code can in turn become tedious and error prone. For example, how do you specify where all the insertions must happen? What if the insertions must be customized somehow for each insertion point? Providing a higher-level conceptual interface to describe such changes is a promising technique [2].
The integration of new feature-handling code into a target application has three components: traversal, selection, and generation. A traversal defines an order in which the transformer will visit the code. (Generally, we consider traversal of code statements within a method, but the principle is similar for ordering the visits of methods or classes.) A filter operates on the output of a traversal, selecting individual join points as necessary or not for a given transformation. Finally, a generator creates a new code sequence to insert at the selected point (technically, it may also edit or remove code); it may alter its behavior based on the context passed to it by the traversal or filter. The simplest and most common type of generator uses a statically defined sequence, but the idea is generalizable to the dynamic creation of custom code. Each of these components can be independently specified and can be replaced by alternate implementations to achieve different goals.
For example, consider a transformation to add the Observable design pattern to a target. Its goal is to insert code that marks the object as dirty wherever a change of state occurs. One possible implementation uses a traversal that iterates through the code by basic block. The filter would identify instructions that modify the state of the object, and the generator would insert code marking the object as dirty. Once the filter had identified a valid target, the traversal could then skip the remainder of the basic block, bundling the notification of observers until the end of the method.