Been doing a bit of thinking on AOP and have realized that all my previous examples of explaining its purpose or usefulness (like logging and security) aren’t very good.

If you aren’t familiar with AOP or its reference implementation, AspectJ, I’ll try to catch you up…

Aspect-oriented programming is a slightly different way of structuring your code. We’re all familiar with OOP architecture, where things are typically organized as a hierarchy of objects with some “main” method starting the show by calling other objects which in turn call other objects.

Component-oriented engineering (or CBD) and service-oriented engineering (or SOA) extend OOP, but are especially good at dealing with “scattered” objects that need to be globally accessible. That is, components that can be clearly separated from the rest of the application, but called from any other object. As I’ve mentioned ad nauseam, the more code placed into these “components” the better, as components can often be reusable from application to application.

But often there are times when some code is similar between two classes such that you don’t want to maintain separate instances in two classes, but the code can’t be extracted and isolated into a separate component, or be placed into a common parent due to the need to have intimate knowledge of the inner workings of the two classes. Here’s a quotable summary:

A software system is the realization of a set of concerns. One of the central premises of object-oriented programming is that each concern should be implemented as a separate module. However, there are certain system-wide concerns, such as logging, security, performance, and so forth, that often need to be addressed in many, if not all of the modules. Consequently, the code to handle these system-wide concerns may be mixed in with the core logic of a huge number of modules, resulting in lower productivity, poor quality, and systems that are hard to evolve.

Aspect-oriented programming overcomes these problems by modularizing the system-wide concerns.

Where AOP works is when a task must be implemented in many classes… what the Aspectists call “cross-cutting”. Basically, AOP is a way to enhance program modularity and wants to solve problems that have no good solution in typical OOP implementations. However, I like this quote from Gregor Kiczales (taken from this theServerSide article):

Used properly, AOP does not violate those principles [of OOP modularity], it helps you achieve them. To see why though, you have to be sure to think about examples where it is appropriate to use AOP, not of examples where plain OO already produced good modularity.

So clearly the best examples are embedded in your current code projects, not in some orthogonal example. If you look at your code, you’ll notice some code that you often put in a parent class. But this class needs some information from the child class in order to work. Typically, we solve this with parameters to our method calls, but often it is these that might make good use of AOP.

Well, I guess in order to implement aspect-oriented programming in Java, it requires some extensions to the Java language, and this extended Java is called AspectJ. While it is a fringe project, it seems to have a lot of momentum and respect. For instance:

• AspectJ won “Most Innovative Java Product or Technology” from JavaWorld

• There are a couple of books out on this subject: “Mastering AspectJ” by Joseph Gradecki and Nicholas Lesiecki and “AspectJ in Action” by Ramnivas Laddad (Bookpool has this one on sale, and some of the chapters are up on theServerSide).

• There is an Eclipse project supporting the extensions. In fact, the AspectJ’s home project is linked with this Eclipse project.

AspectJ (and much of the AOP development) came from Gregor Kiczales from PARC. There is a good interview with him (and a good introduction) on theServerSide. For further reading, check out this list.