Slashdot Mirror
Aspect-Oriented Programming Article On JavaWorld
Some Guy writes: "Javaworld has another article (the second in a series of three) on Aspect-Oriented Programming. Grady Booch wrote last year that AOP is one of three signs of a disruptive software technology in the horizon: a technology that could take us to the next level beyond object-oriented programming."
For those of you not employed in Java-land,
this month's MSDN has an article
about AOP as applicable to COM/COM+/.NET.
--Tim
if you're into java, argoUML (gpl or bsd, iirc) is a decent tool. of course, it's written in java, so you better have a fair dinkum amount of physical ram on your workstation (at least 128, 256 would be better).
and unsurprisingly the inventor of AOP (Gregor Kiczalez) also wrote a book on the meta object protocol (meta programming in CLOS). It's funny how people try to dismiss stuff by comparing it to stuff they do know. Aspects are of course easy to implement in Lisp (just as most other language features we know). The original, quite interesting, paper on AOP at Ecoop '97 even used CLOS for the examples. Lisp is a very powerfull language, however it is also very hard to use.
Kiczalez realized that if he'd stick to lisp, AOP would never work because ordinary C++/Java programmers would never be able to understand it (just like they never grasped meta programming, reflection and whole bunch of other advanced language concepts). Hence he made an implementation of AOP based on Java. One of the design goals was interoperability with Java so that the transition would be as easy as possible.
Now the difference between the visitor pattern and AOP is that the visitor pattern affects the design of your program (i.e. the places where visitors are used must explicitly call a visitor) whereas the usage of aspects is transparent.
Jilles
The confusing thing about AspectJ is that it is really not Java but rather a different language that happens to share a lot of the syntax and is able to compile to bytecode (just like e.g. Jython).
Currently the compiler merely does some preprocessing and then uses the Java compiler but the long term plans are to create a separate, incremental compiler (to improve performance on large projects).
It is also worth pointing out that there's a difference between AOP and AspectJ. AspectJ is one of the many aspect oriented languages. Other examples include IBM's HyperJ and Karl Lieberherr's Demeter Java (do a search on google if you are interested).
AspecJ happens to do most of the weaving statically but this it could just as well do it at run-time. The only problem with that is that this would affect performance since you need to do all sorts of reflective stuff in order to make it work.
The best way of describing what AOP does is to think of your OO system as a graph of objects calling each other. Aspects insert functionality on the paths in this graph that augment e.g. return values or exceptions or introduce new data.
You could for instance insert an aspect that would simply count all accesses of public methods (not particularly useful but the point is that you can). In order to that you would need a static aspect (i.e. all insertion points get the same aspect instance) with an integer and some increment functionality. In addition you would write a pointcut (i.e. a pattern identifying insertion points in the graph) that gives you all the public methods. The AspectJ compiler does the rest.
The whole point of AOP is that counting the public method accesses is a concern that is different from the other functionality in your program. More importantly, in a regular OO program it is a crosscutting concern since you would need to insert functionality in each public method to make it work.
By making it an aspect you separate the concern from the other concerns that your program addresses. Should you for example discover that you would need a long rather than an int, you only have to update the aspect rather than each public method in your program.
Well designed OO programs also exhibit some separation of concerns. Typically you will find stuff like design patterns being used to do so. The price you pay is a more complex design. AOP potentially offers you a cleaner and easier to maintain solution than design patterns. However case studies will need to proof this (this is the primary motivation for creating AspectJ).
Jilles
An aspect is a property of a set of classes or methods.
Hu?
The simplest aspect is a logging aspect:
,,on enter method``
System.out.println(method.name() + " entered");
,,on exit method``
System.out.println(method.name() + " left");
Now say:
,,all classes in package foo use aspect enter method and exit method``
A aspect weaver (somthing like an OO object code morpher) now injects the two aspects into all methods of the package foo.
Aspect oriented programming is about "grasping" ideas, code fragments, which are smaler than methods but can be regular expressed (like a regular expression).
Similar concerns are described in one aspect, its like a class consisting out of code fragments.
Then you write your classes without repetitive enter/exit -- or other -- patterns in their methods.
Finaly you weave classes and aspects together into an executeable.
There is a somewhat similar new way of programing: subject oriented programming.
See "hyperj" at ibm.aphaworks.com.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.