Slashdot Mirror
Aspect-Oriented Programming with AspectJ
He has divided the book into four parts. Part I provides a brief sketch of AOP and introduces its concepts. AOP builds on OOP, asserting that we need a new programming entity called, wait for it, an aspect. Mr Kiselev's explanation of aspects reminded me of that bit in The Hitchhiker's Guide to the Galaxy when the planet Golgafrincham divided its population into A types (who were the leaders, the scientists and the great artists), the C types (who were the people who did all the actual making of things and doing of things), and the B types, who comprised everybody left over: telephone sanitizers, advertising account executives and hairdressers. As I understand Mr Kiselev, the AOP view of things is that objects and classes (A type thinkers) and low-level procedures and APIs (C type doers) can be nicely encapsulated using traditional components. But aspects, software's little hairdressers, get their fingers into everything, and until now there has been no way to encapsulate them. This of course is what AOP in general and specifically the AspectJ superset of the Java language set out to do.
AspectJ's eponymous aspects are constructs not unlike ordinary classes. Mr Kiselev has not resisted the temptation to make an aspect Hello World example, and it looks reassuringly so-whatish:
package intro;
import java.io.*;
public aspect HelloWorldA
{
public static void main(String args[])
{
System.out.println(Hello, world!);
}
}
Mr Kiselev then lays out his stall of New Things. A join point is any point in execution flow that AspectJ can identify and -- to get slightly ahead of ourselves -- execute some extra code. The most frequently used kind of join point being the call to a method. Pointcuts specify collections of join points; as a regular expression is to an instance of matched text, so a pointcut is to a matching join point. An advice (with horrid plural 'advices') is the code to be executed when a given pointcut is matched. If you are familiar with Eiffel's pre- and post-conditions, then you'll understand if I say that it is common for advices to run in the same way, topping and/or tailing the execution of a method. The differences are that aspects are specified from outside the method without touching the method or its class's code, and that aspects can be applied to multiple methods in one go. Mr Kiselev concludes this section of the book with a few simplistic examples of 'here is class A, here is class B' kind.
In Part II Mr Kiselev rolls up his sleeves and takes us through an extended, realistic example. I did wonder if perhaps it weren't a wee bit too realistic, as it is a miniature website application for news story submission and reading -- sort of Slashdot Ultralite -- all done using JSP and a MySQL database. Just explaining this setup, without even using any AspectJ, consumes a 15-page chapter. Since I am a C++ programmer who has not had any contact with JSP, I was initially anxious that I might not be able to follow this. However, recalling that www.[name withheld].com, the clumsiest, ugliest corporate website on the Internet, is programmed in JSP, I reasoned that if the dolts that programmed that site could understand JSP then it couldn't be very hard. So it proved.
The first example comprises adding password protection to the application. This is achieved by adding an advice that intercepts calls to doStartTag() methods. The advice can test if the user is logged in and, if he isn't, throw an exception that will dump him back at the login page. (Who says exceptions aren't 21st century gotos?) At this point Mr Kiselev admits that the cute 10-line implementation that he initially shows is in reality a non-starter; for one thing not all pages that must be secured define doStartTag() methods, for another the aspect can't reach an instance variable it needs to read because it is declared in protected scope. The second problem is easily overcome. AOP offers a mechanism by which extra classes can be bodged ('introduced' is the preferred verb in the AOP community) into the hierarchy as parents of existing classes. He uses this to add an accessor method for the field in question. The other problem is not so neatly smothered, and it is somewhat ruefully that Mr Kiselev produces his final, two-page solution. But I think that it is greatly to Mr K's credit that he does this - it tastes like programming in the real world as I have experienced it.
For the rest of Part II, Mr K demonstrates other applications of AOP using the AspectNews code. This includes Eiffelish design-by-contract stuff, improved exception handling, various debugging and tuning techniques (specifically logging, tracing and profiling) and a chapter on runtime improvements - stream buffering, database connection pooling and result caching - which show the AOP way to do things, usually where I would expect to be putting in proxy classes.
In part III we get down and dirty with the AspectJ language. This is the part where the book explains the obscure stuff: how to make a pointcut that picks up object preinitialization, or make an advice that goes off only when you are exiting a method on the back of an exception. I skimmed this bit - I guess it will become vital when I start using AspectJ in earnest. It looked good and clear on a flick through. A brief part IV contains some patterns, to give one a start when engaging AspectJ in earnest. Apparently it is horribly easy to create infinitely recursive situations, so if you here a faint popping sound from your machine it will be the stack colliding with the heap. There are seven appendices, supplying such things as a summary of the API in AspectJ's packages and hints on obtaining and using the Open Source supplementary tools mentioned in the book (Tomcat JSP container, MySQL database and Ant make replacement). AspectJ itself, now escaped from Xerox PARC, can be downloaded from the Eclipse website.
Complaints? None really. Oh all right, here's a nitpicklette because it's you: at page 75 Mr Kiselev adopts the irritating Internet habit of writing 'loosing' when he means 'losing'. Note to publisher SAMS proofreaders: do I win 25 cents?
For the rest, this is a lucid and readable book that describes the Next Big Methodology. I'm a bit alarmed at the prospect of squeezing new actions into the cracks of existing code, but I dare say I'll grow to love it.
A word of warning to the eager: since this technology is currently implemented as a species of preprocessor that relies on having all the source code available at once, so it is rather slow and probably isn't going into production shops for a while. There again, I seem to remember the comparable Cfront C++ compiler doing rather well, before we had platform-native C++ compilers.
And to the sceptics: if you think you can ignore AOP, don't forget the fate of the A and C type inhabitants of Golgafrincham, who having sent their B type telephone sanitizers into exile were all wiped out by a germ caught from a particularly dirty telephone.
You can purchase Aspect-Oriented Programming with AspectJ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
AOP would seem to let you over-ride methods or invoke special handling *without* touching the object directly. You simply tell the compiler "When this method is called, do this first (or afterwards)."
On the one hand, this could lead to spagetti code nightmares, since execution paths could become effectively untraceable. On the other, it's in many ways cleaner than putting your special-case or over-ride code directly into the methods and objects directly.
--Dave
Aspects are cross-cutting concerns, they are things that cut through numbers of classes. My way of thinking: draw vertical rectangles side-by-side and call these "classes", now draw a horizontal box that cuts through them all and this is an "aspect".
The simple example, and one used in the book I believe, is that of logging. Say you have to log the entry to and exit from every single method in your code. Typically you would probably write this directly putting "entering XYZ, exitting XYZ" actually in the code. But with aspects you can write one aspect that basically says "on entry to any method log the method and parameters, on exit log the method" and compile your code and away you go.
So? Why would I want to do this? Well, now that you have been through your development process and discovered everything runs fine, you decide to go into production. Want to remove every single log line to improve speed? With the "normal" approach you'll have to write a script to remove them or do it manually. With aspects: just dont use the aspect in the compilation! Put them back in by compiling in the aspect again.
For me aspects are a real benefit but they do you head in for a while when you're an OO programmer!
Take advantage of both languages.u ages.ht ml
Of course, as everyone knows, there are Scheme/Lisp implementetions in Java:
http://grunge.cs.tu-berlin.de/~tolk/vmlang
Ones that act as interpreters or compilers to Java byte code.
Or write your own (it's not that hard) http://www.paulgraham.com/rootsoflisp.html
-... ---
Since AspectJ is getting some attention I figured i would point out some other AOP resources
How about blocks in Java, or functors in the Jakarta Commons Sandbox?
Yeah, this review didn't introduce AOP that well.
g i/~checkout~/aspectj-home/doc/progguide/index.html
Going here:
http://dev.eclipse.org/viewcvs/indextech.c
I found this code example:
pointcut move(): call(void FigureElement.setXY(int,int)) ||
call(void Point.setX(int)) ||
call(void Point.setY(int)) ||
call(void Line.setP1(Point)) ||
call(void Line.setP2(Point));
and then this:
after(): move() {
System.out.println("A figure element moved.");
}
As you can see, "after" any method call as defined by the pointcut, System.out.println is executed to reflect this fact.
I can see how this would be great for logging, checking pre/post conditions, quicker debugging, or anything else that is of a "horizontal" nature in your code.
Aspect-oriented programming (AOP) is a new language paradigm proposed for cleanly modularizing the crosscutting structure of concerns such as exception handling, synchronization, performance optimizations, and r esource sharing,that are usually difficult to express cleanly in source code using existing programming techniques. AOP can control such code tangling and make the underlying concerns more apparent, making programs easier to develop and maintain. In aspect-oriented programs, the basic program unit is an aspect. An aspect with its encapsulation of state with associated advice, introductions, and methods (operations) is a significantly different abstraction in comparison to the procedure units within procedural programs or class units within object-oriented programs. The inclusion of join points in an aspect further complicates the static and dynamic relations between aspects and classes My humble request:Please take a moment to use Google before you feel the urge to click the submit button here:-)\
The Software Practices Lab at UBC has been doing all sorts of AOP research lately. Of particular interest:
They're also working on AspectC and AspectSmalltalk. It's my understanding that UBC is one of the major world centers in AOP research -- do you think I should do a PhD there?
Want to remove every single log line to improve speed? With the "normal" approach you'll have to write a script to remove them or do it manually.
.h file, re-compile and you're golden. That removes all the #ifdef debug code you put in when you were writing it.
Or you change one #define in one
Do they teach programmers anything useful these days? Sheesh.
Lemon curry?
I'd have to disagree that it won't be used in production shops any time soon. It's really a matter of the word getting out, which undoubtedly will be helped by both the book and the appearance of this review on /.
A team I was on early last year had a legacy Java db access module that was rife with poor exception handling. We wrote a single aspect that joined on all exceptions, trapping only JDBC exceptions, and had the aspect trap the SQL error code, the ISAM error code, the offending method and source code line. After recompiling the module with the aspect included, we popped the new JAR into production and used the trace files to find the offending code. Altogether it took 2 days to address the errors. So we re-recompiled the JAR, this time with the aspect removed, into production it went, and received a few beers for our "inventiveness."
Honestly, this is one of the most useful Java tools I've ever run across. I guess I should have sent the PARC guys money for some tallboys.
Gregor Kiczales, the lead on the AspectJ project, wrote "The Art of the Metaobject Protocol", which was a description of how to do metaobjects in Lisp (metaobjects, and particularly generic functions, are closely related to AOP). A description that Gabriel and Steele put together can be found in The Common Lisp Object System: An Overview
is not really a real person but is one of the funniest tech writers out there. She is famous for the history of the microcomputer, and is widely and deeply revered by everybody who's read her
She also did a parody of our own Slashdot, which is absolutely f*cking hilarious.
I strongly recommend anyone who hasn't read any stob to go and check out the archives and then laugh yourself stupid for half an hour.
Build your own website - full service homepage system your m