is the most popular and highest rated AOP book on Amazon.
Jacobson's book is probably better read after getting some experience with an AOP-capable language.Book review by Ted Felix
Aspect-Oriented Programming (AOP) is simply a fancy name for code injection. Imagine being able to inject lines of code into a function, functions into classes, member variables into classes, and entire classes into a system. This is what AOP is.
Aspect-Oriented Software Development (AOSD) is Jacobson and Ng's proposal that we use AOP to organize code by use case. In the early days of programming, functions were the only organizing structure. Next we had objects which allowed us to group functions and data together. Now, with AOSD and AOP, we can organize code by use case. A single source code file can contain all the functions (for several different classes), member variables, and even code snippets that are needed to implement a use case. These pieces get injected (via AOP features) into an empty class hierarchy by the "Aspect Weaver" (code injector). The output of the weaver is then compiled by the compiler.
The idea is that when a user reports a problem with a system, it will be in the context of some use case. E.g. "I'm having trouble adding a user to the system." The chances are good there's an "Add User" use case in this system. By going to the file that contains all the code for that use case, one should be able to quickly track down the problem. Without organizing code by use case, one would have to trace through the code from function-to-function and class-to-class until the problem is found.
It is very hard to tell from a book how well these ideas would actually work in practice. It seems like AOSD introduces a whole new level of complexity. Imagine trying to debug code and having to search around for other code that might have been injected to figure out what is going on. Injection is similar to inheritance where one must look somewhere else (the base class) to see where functionality is. The combination of inheritance and injection seems like it could be quite overwhelming. It would take some real experience with a real AOSD project to get a feel for the weaknesses of the approach and whether they are serious.
"Aspect" is a fancy marketing term for how code injection might be used. One could inject "aspects" of a system (like logging) into the uncluttered main code. If Object-Oriented programming were named this way it might have been called "Responsibility-Oriented Programming" since objects can be used to encapsulate a coherent set of responsibilities. AOP should be called "Injection-Oriented Programming". But then, it loses some of its marketing mystique.
Code injection is most useful for debugging and testing, and this is where it will have its best chance at becoming mainstream. With only a few lines of code, you can inject something (like logging) into every function in a system. Then, by simply removing this logging "Aspect", all of the logging code is removed. Test code, debug logging, and test stubs can also be injected into a system without changing the code being tested.
"If you are a risk-adverse [sic] person, then testing represents the most profitable area for you to apply our approach. Testing often requires the introduction of control and instrumentation code. With use-case slices, you can, in a blink, remove all such code from the final delivered system. Thus, it is a small wonder that the logging example is one of the most frequently used examples to introduce aspect orientation. You want to remove such instrumentation code in the final system and, hence, aspect orientation is a welcome solution to many project teams" (373).
Note: As is typical of Jacobson's books, this one is filled with typos. The above is a good example. It should be "risk-averse".
The terms weaving and composing both refer to performing the code injection prior to compilation.
Organizing code by use case makes it difficult to create good classes. The code is organized by use case, and the classes are empty. If you can't see the composed classes, you can't evaluate them. You also cannot see what features a class already has so that you can make worthwhile improvements. "When you evaluate a [class], you must consider it in a composed manner..." (325) To do AOSD, you must have some sort of a tool that will let you preview the composed system so that you can make good class design decisions. This would also help in debugging injected code to figure out why things aren't working. Code injection means you aren't looking at the actual code until you compose the system. This seems like it might be a rather serious drawback in practice.
Also note that encapsulation is easily violated with AOP by simply injecting a public function into a class that exposes private data. For those who are unscrupulous, this is a tempting approach.
I've always known that to design an extensible system, you must predict the future. The authors support this belief. "To evaluate extensibility, you must first think about what kind of enhancements you want and what kinds of changes you might have. These are called change cases" (332).
I like reading a book that presents a new way to think about software, and this one does. The ability to inject code is an interesting new way to solve problems yet keep code simple. This book shows how code injection could be used to organize code into use cases. While this might be of limited value in practice, the implication is that one could arrange software in many different ways. By showing us this application of code injection, the authors stimulate our imaginations to come up with our own applications for code injection.
If you are interested in what Aspect-Oriented Programming is all about, this is a good book to read. However, there are books on AspectJ (the Aspect-Oriented flavor of Java) that might be more useful if you want to get some real experience with AOP.
As of 4/2007,
AspectJ in Action (Laddad 2003)
The full price of this book is $54.99, yet I was able to easily pick up a practically untouched copy for $12 including shipping. This huge price differential indicates that this book is not very popular. In fact, all of the aspect oriented books on Amazon have a large new/used price differential. The fact that there are only about 10 AOP books available seems to indicated that AOP isn't gaining much popularity as of 4/2007. I think it will be quite some time before AOP and AOSD become mainstream, if ever. AOP's use as a debugging tool will win people over first.
If you found this review helpful and you plan to buy the book, click on this link to buy the book from Amazon:
Aspect-Oriented Software Development with Use Cases (The Addison-Wesley Object Technology Series)
A portion of the sale will go to help support this website. Thanks.
Read from 3/2/2007 to 4/1/2007.
<- Back to my software books page.
Copyright ©2007, Ted Felix. Disclaimer