A Primer for Aspect-Oriented Programming in Java
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Java AOP Basics
Aspect-oriented programming (AOP), although far from a new topic, has recently become quite a hot one. Many folks in the coding industry are touting AOP as the successor to the object-oriented programming (OOP) model; however, as we'll see in this article, despite a similar acronym AOP addresses few if any of the same concerns as OOP. In short, AOP allows for code behavior to be divided into core components (aspects), which can be injected into arbitrary locations easily. Method calls can be intercepted, augmented, or redirected, as can field access and even inheritance—in many cases without code changes.
Whereas OOP doctrine is to group functionality into objects and create relationships between those objects, AOP says to think of functionality (here called aspects or concerns) as being independent from any class. AOP primarily deals with what are called crosscutting concerns, which are aspects of functionality that are needed but are unrelated to the actual behavior of the class in which they're needed. The prototypical (and overused) example is logging—something that most applications must provide, but that generally has nothing to do with the applications or their objects. AOP doctrine says to abstract such aspects of applications, in order to make them accessible regardless of class inheritance.
Aspects can be plugged into code at join points—places such as method calls, field access, and exception handling. You must give instructions (advice in AOP-speak) for what to do at these join points. Exactly how you provide advice differs widely depending on which AOP implementation you're using, but often it's via something like an XML configuration file or metadata within code, generally using something like regular expressions to identify join points.
AOP also gives developers access to compile-time behavior much like multiple inheritance, called introductions. With introductions, you can force a certain class to implement a separate interface, without touching the code of the class itself.
Plenty of other functionality is provided, and many implementations of AOP have their own additional features. AOP has a lot of power when changing application behavior, but the ease with which these changes can be implemented and the way in which code execution can be modified outside the code itself is bound to cause serious headaches for some developers. We'll touch on this topic again, but now that we have the lingo down, let's look at an example.
NOTE
We'll use the JBoss implementation of AOP, as its way of describing rules of advice via XML configuration files means that we can quickly and easily handle most AOP functionality without modifying or recompiling our example. Also, for the scope of this example, JBoss AOP relies only on the Sun Java compiler and runtime, along with its own libraries. Other Java AOP implementations use keywords and extensions to the Java language itself, relying on non–Sun compilers to generate their classes. There are advantages to each type of implementation, but in this simple example JBoss makes our work easier.