Aspect-Oriented Programming with AspectJ 496
Aspect-Oriented Programming with AspectJ | |
author | Ivan Kiselev |
pages | 274 |
publisher | SAMS |
rating | Excellent |
reviewer | Verity Stob |
ISBN | 0672324105 |
summary | Introduction to a new programming technique using an extension to Java |
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.
So, what is this? (Score:2, Interesting)
Re:So, what is this? (Score:3, Insightful)
From what the reviewer talked about with A types, B types and C types, it sounds a whole lot like roles and the delegation design pattern.
Agree? Disagree?
Re:So, what is this? (Score:3, Interesting)
There's quite a bit of repetitive code created (copied & pasted, then search & replaced) when you make a delegator. Hopefully, Aspect-Oriented would let you skip the mechanical work of writing a delegator, and just get on to using it.
You might describe it as the programming language compiler becoming aware of a pattern, and learning to implement it when told.
Here is what it is: (Score:3, Informative)
Short answer: Yes, it is the Next Big Thing.
In the same sort of way that procedures were already implemented by experienced programmers long before languages like Pascal came to be,
In the same sort of way that experienced programmers used virtual function lookup tables and information hiding before OOP came about,
So is AOP. It is program-language-level support for the sorts of things experienced programmers do already... namely, code generation and automatic code modification.
Basically the reason OOP came about was that there was no means to add functionality to code without going into that code and inserting a call to the new functionality. Experienced programmers made virtual functions and lookup tables to solve this issue, but obviously this sort of code is complex and prone to error. So OOP brought forth program-language-level support for this sort of feature.
The problem that AOP addresses is this: As powerful as OOP is, it still relies on functional decomposition. The trouble is, sometimes one thing changes that cuts across functional boundaries. For example, the performance of an application, when ported to a new system, may need an entirely different set of performance tuning for the new app. Or more likely, you simply didn't see some aspect (there's that word) of your code changing often, and it would be impossible to separate it into a module without restructuring your entire code.
Now you can do a lot of inline #ifdef's and the like to do this by hand. Or, you can use some sort of dynamic code generation. But writing a dynamic code generator by hand is, like the virtual function table example above, tricky and always ad hoc.
The ultimate goal behind AOP is to make code generation generalized and done at the language level. So that you can modify things that occur across the boundaries of the existing functional decomposition.
Does that make any sense?
Re:So, what is this? (Score:5, Insightful)
Basically, imagine if you wrote a program which had "hooks" scattered through it. As you write your code, you place hooks for before/after doing many things: reading user input, transmitting network data, accessing preference files, checking permissions, etc. (Imagine wrapping all your function calls with dynamically-bound functions which you don't yet know if map to an identity function, or have some effect)
Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).
Now, imagine than rather than the programming having to plan ahead to scatter hooks all around his code (uglifying it towards readers who don't care about them), they are inserted automatically by the compiler.
So a person can create a function which will be automatically called whenever some other set of 3 different functions is called, without having to go modify each one. Instead of going to each function body and adding a call, he at one position attaches his code to functions of that kind. The program is shorter, but has more effects. This may mean, when all goes well, that if someone adds a new function with similar effects, those hooks may still get called.
Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?
In both those cases, the program is doing things that the source code doesn't make 100% clear to a programmer reading a single function body. This can be either good or bad. The usage of editing tools which evaluate the code and alert the reader to these facts (analogous to "class browsers" in several IDEs) shift it much further towards "good".
Re:So, what is this? (Score:5, Interesting)
It's my opinion that, if you have to ask that question, then you and everyone else on your team are doing AOP in a bad way. The entire function of AOP is to separate disjoint concerns so that you don't think about them when you're programming. You write application logic. Your fellow team member maintains your security aspect. You don't ask "When I call this method, will it trigger the security aspect?". Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.
Long story short- if two separated concerns in AOP have such a sufficient dependency that you have to ask yourself a question like that, then they should not be separate concerns at all. At least, in my opinion.
Re:So, what is this? (Score:2)
Which will inavoidably lead to very bad code. Remember operator overloading in C++, where a similiar overuling of semantics was possible? Because of its abusive potential it was one of features that became considered bad practice if used at all later.
Regards,
Marc
Re:So, what is this? (Score:3, Insightful)
Only dumb programmers become any more confused by operator overloading than by other kinds of overloaded functions.
I don't want to reduce the effectiveness of the smart ones by sheparding the stupid.
Re:So, what is this? (Score:2)
Imagine what would happen if one of these AOP folks would try to sell it to Dijkstra ("Go To Statement Considered Harmful", Communications of the ACM, Vol. 11 (2), pp. 147-148, 1968).
Regards,
Marc
Re:So, what is this? (Score:3, Informative)
How far would AOP meet with his approval? Good enough, it seems. Dijkstra's criteria [acm.org] for allowing a feature into a language was how much it complicated the description of the "cursor position" ("textual index point") of a program at a certain time. Gotos are bad, because they make the size required to describe that position unbounded (the full history of all previous goto jumps). Structured programming, with nested blocks and function calls, keeps the size limited, because the position-descriptor shrinks when you leave a block. (As long as there's no infinite recursion, but even that can sometimes be handled)
AOP's effect on the execution graph is the same as function calls. It's just the calling of functions, but the calls themselves are implicit and invisible. The textual index size is only increased by a small constant factor per aspect called, and that size is recovered when it's done.
Re:So, what is this? (Score:3, Interesting)
Bounded and large would be worse enough. Let me rather cite:
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
AOP, like operator overloading in C++, can introduce amazing surprises to a programmer. A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.
Regards,
Marc
Re:So, what is this? (Score:3, Interesting)
That's a true statement about any program. Just try tossing in a random uninitialized pointer or runtime exception here or there in any utility function, rebuild, and see what happens.
I've written "aspect"-like code before... a system that I worked on not too long ago (hey, Honus!) made use of a pretty nice set of functions and macros in order to:
This involved manually adding the appropriate macro at the start and end of each function. A pain in the butt, and the inevitable tyop came back to bite you hard :-/ IMHO, this is the type of problem that aspect oriented programming is intended to solve.
Yah, improperly coding an aspect could cause all sorts of heartache and difficult to solve problems. But... when we did the same thing by hand, it still caused heartache and difficult to solve problems. I'll take AOP (supported by an AOP-aware debugger) over doing this sort of thing by hand any day of the week.
Re:So, what is this? (Score:3, Interesting)
Re:So, what is this? (Score:3, Informative)
Re:So, what is this? (Score:5, Insightful)
Aspect Oriented programming is a brand new programming paradign, kinda of like the switch you made when going from functional programming to object oriented programming. It's a different way of expressing your programs
The reason that Aspect Oriented Programming was created was due to "cross-cutting" concerns that cannot be easily modelled in object oriented programming. I read the presentation for AspectJ and the example they used was logging in Apache Tomcat. Bascially the code that is used for logging is scattered throughout the whole program on hundreads of different lines, not all in one nice neat class. Aspect Oriented Programming wants to give the programmer the tools to gather all of this code together.
Bascially, Aspect Oriented Programming is supposed to result in: less tangled code (code that is fragmented throughout your program because you are unable to modularize it well), more natural code, shorter code, easier to maintain and evolve, and more reusability.
One question I had about the book that the review didn't seem to answer was did the book talk at all about designing using Aspect Oriented Programming? Just like Object Oriented Programming, it's a great tool until you get some inexperienced programmer who just knows how to program functionally, and thus doesn't use the advantages of aspect oriented programming. I too would like to learn more about how to go about designing a program in an Aspect Oriented way; such as how to identify aspects, what are some common aspects, etc.
In all, I'm very excited about Aspect Oriented programming. I think it has the ability to allow programming to shape thier programs more naturally, make their programs easier to understand, and make the whole process much eaiser. But of course as with any new technology, it has some growth and refinement to go through yet.
Those of you who would like more information can check out the AspectJ [eclipse.org] webpage, or the Aspect Oriented Software Design [aosd.net] webpage.
Re:So, what is this? (Score:4, Insightful)
What is Aspect-Oriented Programming?? I've never heard of it!
the gimmick dejour. yet another programming methodology that hopes (in vain) to eliminate the need for skilled programmers.
Once again someone proves the old saying Better to keep your mouth closed and be thought a fool than to open it and remove all doubt. I can see why the above response was submitted anonymously.
The goal of Aspect-Oriented programming is not to eliminate the need for skilled programmers. The goal is to reduce the local complexity of code. Make it so that when you look at code who's job is to store some data, it isn't cluttered with all of the other code like debugging and error handling. The point of this isn't to remove that code all together, but rather to make it much less tightly coupled. Why should persistence code be married to logging code? The answer is it shouldn't, they are two entirely different functions. Aspect-Oriented programming makes it easier to decouple them. This makes both pieces of code more flexible, and reusable.
Re:So, what is this? (Score:2)
its obvious that AOP will succeed where OOP, Top-Down Design, UML, and JAD failed.
its another stupid methodology that appdev shops will spend lots of money chasing.
Well OOP, UML and JAD are all usefull tools for developing software. They may not always be the most appropriate tools for solving the problem at hand, but it is silly to discard them out of hand. It's kind of like woodworking, an adz insn't always the appropriate tool for solving the problem, but when it is, you are glad that you've got it.
Re:So, what is this? (Score:4, Funny)
I don't know if I am just becoming old and closed-minded, or if there were too many methodologies-de-jour in the last years.
And please note that some schools of programming, like some disciples of the school of functional programming think that even OOP was snake oil!
Man I wish Microsoft or Sun would hype Visual OCaml or Erlang2EE or Prolog.NET for a change. That would be refreshing.
Regards,
Marc
I prefer reading... (Score:5, Funny)
This book contains every programming concepts and practices to avoid like hell!
Re:I prefer reading... (Score:3, Insightful)
This is from /usr/src/linux/Documentation/CodingStyle
Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.
Re:I prefer reading... (Score:3, Insightful)
And Code Complete really isn't a bad book at all. It may give you some false starts and misdirections, but it will definitely make you think about aspects of software development methodology.
Fascinating (Score:5, Funny)
Re:Fascinating (Score:2, Funny)
Yet another reason to switch to Lisp (Score:5, Insightful)
Once you've used a language like Lisp with closures, macros (at the language level, not wimpy C macros), and code-is-data, it's hard to go back. I feel sorry for everybody who has to use Java, for whatever reason, and will have to get a new language/compiler/libraries just to take advantage of a slight change in "what's hot today".
Re:Yet another reason to switch to Lisp (Score:2)
Never trust a language with more brackets than code...
Cheers,
Ian
Re:Yet another reason to switch to Lisp (Score:3, Insightful)
How about XML?
Besides, every language has barackets. Just in Lisp all bracket are unified to be as (). Other languages use various forms of brackets: (), {}, [], ";", "new-line". Python use even space identation instead of brackets (the only thing I hate in Python!).
When the code is the data, unified brackets are much better for verification purposes. That's why XML also has unified brackets (just badly designed, IMHO).
Re:Yet another reason to switch to Lisp (Score:4, Informative)
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
Workarounds? (Score:4, Informative)
Re:Yet another reason to switch to Lisp (Score:2)
That's why after almost 50 years, it still hasn't taken over the world. Moreover, while code that operates on code is extremely powerful, it can be one of the most mind-boggling features in all of CS. In a world where many developers can't understand simple recursion, it's probably just too advanced for general consumption.
I think languages like Python and Ruby (especially use is made of their functional programming features) find the happy medium between powerful features and approachability.
Re:Yet another reason to switch to Lisp (Score:5, Insightful)
(5 256 "Item" "Description") represents your base data type.
Programmer A:
"I don't need that first number..."
(256 "Item" "Description")
Programmer B (who get's A's data):
"What happened to that number?"
(256 "Item" "Description" 5)
Programmer C (who get's B's data):
"Strings? We don't need no stinking strings, we can look those up in a table! I can make that table global! Sweet!"
(256 1 20 5)
Person hired 2 years later to fix a bug:
"What the f*ck?!?"
It seems to me that Scheme and Lisp over-extended themselves, and are just too powerful/flexible for their own good, and that some "rules" should be in place...
And as the previous poster said...
((((()()))))
Lisp will make you hate parenthesis.
C
Re:Yet another reason to switch to Lisp (Score:3, Insightful)
Programmer 1:
struct Part {
int number;
string name;
string description;
int count;
};
Programmer 2:
Oh, how inefficient; let's just replace that
with integers and put the strings into a
"resource table" somewhere.
typedef int Part[4];
In fact, by using atoms rather than strings,
the Lisp programmer can achieve the efficiency
of C++ Program 2 while essentially preserving
the appearance of Program 1.
Note that the correct way of defining the
data structure would be with DEFSTRUCT or
as a CLOS object.
As for the parentheses, people who sit in
glass houses shouldn't throw stones: C/C++
syntax has numerous flaws. Is syntax like this
really better?
a[((unsigned)*(short*)b)]
What about expressions like "a = b << c + d";
do you really know how the precedences work out?
Lisp syntax, with the right editor, is easy
to input and easy to read. And unlike C/C++
syntax, it doesn't have any precedence issues
and it is extensible.
Re:Yet another reason to switch to Lisp (Score:3, Insightful)
What I got from the review is simply further confirmation of Paul Graham's [paulgraham.com] hypothesis that more modern programming languages are asymptotically approaching the capabilities Lisp has had for decades.
The whole "join points / pointcuts" thing seems to me like a watered-down version of Scheme's (and other Lisps) dynamic-wind and call/cc.
(And didn't the B-type Golgafrinchans end up populating some utterly insignificant little blue-green planet orbiting a small unregarded yellow sun far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy?
Re:Yet another reason to switch to Lisp (Score:2)
Re:Yet another reason to switch to Lisp (Score:3, Interesting)
Bad code (Score:4, Funny)
Where are the quotes?
I dont trust this guy if he cant write a HelloWorld app.
Re:Bad code (Score:2)
It's why I only resort to using prewritten code when necessary because I know I'm just going to have to debug the hell out of it and effectivly end up rewritting it.
I even had the displeasure of asking a question on a forum and being given some code that I knew wouldn't work because I even told the person why the functions he used wouldn't work before he wrote up some crappy and obviously untested code using them. It wasted my time and his time.
I never understood why people post crap code. I'd rather be unknown than be made irrelavent and avoided by posting untested and non working code which serves only to annoy people.
Ben
So, what is it? (Score:2)
Re:So, what is it? (Score:3, Informative)
What is Aspect Oriented? (Score:2)
Re:What is Aspect Oriented? (Score:2, Informative)
Re:What is Aspect Oriented? (Score:3, Informative)
This is precisely what I use AOP for. Whilst there is tremendous opportunity for spaghetti coding, so long as you adhere to some reasonable standard of layout and documentation it works out much more maintainable for certain design patterns.
Re:What is Aspect Oriented? (Score:2)
Sounds like pre-post "exception" handling (Score:3, Insightful)
A methodology hasn't made really made it until somebody has published a Proper Book
Are they kidding. Hell there probably books out here on clipping your finger nails using a new methodology. Now days having a book don't mean squat (unless you're a tree, beaver, or a bird).
Re:Sounds like pre-post "exception" handling (Score:2)
I know, that's why every time I say "exception", I placed it in quotes. I was relating the physical mechanism to something similar in C++.
Re:Sounds like pre-post "exception" handling (Score:2)
This is not good (Score:2, Insightful)
Re:This is not good (Score:3, Interesting)
This attitude is already pretty common. "Oh, we can't understand what this library does, so we'll write a transparent wrapper which instruments all function calls, so we can gain a clear picture of what's going on"
If AOP was used, then at least when a programmer decides he's got to throw a wrapper on something, he can do it with a few lines of code (define an aspect on the classname, using wildcards), rather than spending all day to copy & paste every single function in the class and add his 3 lines of "instrumentation".
And then when his foolish adventure is done, and the extra code is nothing more than a drag on performance, it can be removed (or just disabled) from a single place, rather than once again scrolling through all of a class's source code to touch each and every method.
Re:This is not good (Score:2, Insightful)
To sum up (Score:2, Insightful)
Okay, so there are some objects that don't act like objects, so he wants to call them aspects and give them more power and scope throughout an application.
The main concern is while this may improve a program, I see 'aspects' being dropped in favor of meeting a deadline.
Re:To sum up (Score:2)
(fortunately, the day was saved by an 'object that doesn't act like an object')
Damn, performance is screwed... let's get the preprocessor to remove our logging calls! Oh, it's Java...
(Fortunately, AOP was enforced. We can easily just remove that aspect)
Eclipse Project makes AspectJ more mainstream (Score:5, Informative)
This letter [eclipse.org] announces that AspectJ [eclipse.org] is no longer at aspectj.org as it has moved to the Eclipse project [eclipse.org].
I think this is a very good thing since Eclipse is one of the most popular Java development tools, and is concerned with good coding practices like refactoring and coding helpers. Plugins allow people to add their own stuff. With this, people who haven't heard of AspectJ or Aspect-oriented programming would take a look.
Interestingly, the Eclipse homepage does not explicitly mention Java. It says, "Eclipse is a kind of universal tool platform - an open extensible IDE for anything and nothing in particular." Personally, I have only used it for traditional Java. [kalixia.com]
My 2 bits... (Score:5, Insightful)
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
By and large, the more I work in java, and the more I work in Lisp, I realize how lacking java is in dynamic behaviors. The lisp guys yawned when OO became all the rage because, well, it is so easy to do in lisp. If AOP gets big in java, they will yawn at that too:
"Oh, so functions and try blocks are your boundry block for inserting aspect oriented code? Well, *every parenthisis* is ours. Put that in your JVM and smoke it."
Cheers,
prat
Re:My 2 bits... (Score:5, Insightful)
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
Sure, of course you can. AOP is a technique, supported by tools, it doesn't need to be hoodoo magic to be useful. Mind you, like you said, it'll get you 50% of the way. You can get 50% of the benefits of assertions by writing a static Assert class and using it consistently. It's just that it is nice to have capabilities either built into the language to support good practices, or extensions to the language (a la AspectJ) to support them.
And the List thing is tired. We all know that Java is limited. It's limited compared to C++, it's limited compared to Lisp. Ya know what? That's a good thing. For large software development projects with many engineers involved. I can pick up other people's code and not worry about whether X really means X or whether it's a macro that's been defined elsewhere to mean Y. I realize my view on this isn't the most popular on Slashdot, but that's probably because people haven't had to manage teams of developers who aren't populated throughout with brilliant coders, capable of writing fast, functional readable code in languages that leave n degrees of freedom.
Adding capabilities to a language to support a particular kind of new programming paradigm is not unreasonable. I realize that the fact an extension to the language is needed seems like a limitation, and it is, but like I said, that limitation can be a godsend, and it's worth the tradeoff.
Of course, when I'm working on my own time on my own projects, I far prefer to use a manly language like C++, or a pleasant language like Python.
Re:My 2 bits... (Score:4, Informative)
Portable.NET uses AOP for the C# compiler: treecc (Score:3, Insightful)
http://www.southern-storm.com.au/treecc_essay.h
http://www.southern-storm.com.au/treecc.html
h
It is also rumored that Portable.NET will use treecc for the creation of a JIT engine sometime in the future.
From my limited understanding, Aspect Oriented Programming combines the power of the Visitor and Inheritance patterns without the drawbacks of either.
Another interesting link:
http://www.pcmag.com/article2/0,4149,44061
Re:Portable.NET uses AOP for the C# compiler: tree (Score:2)
treecc was specifically designed to aid in compiler design and it turns out that this is one of the examples that make for a good AOP solution. This is the relevant blurb from Rhys's article on treecc:
People are still adapting to the last big thing (Score:2)
I see plenty of crappy code all the time. I see lousy use of OOD/OOP. People haven't even adapted to OOD/OOP very well. I can't see this being much more than a technique curiosity that may solve some needs here and there for quite some time to come.
Re:People are still adapting to the last big thing (Score:2)
In the end, however, it is still limited by the ability of the programmers who are using it - as is OOD/OOP and indeed any programming style at all...
How true (Score:5, Funny)
Yup. Nothing can save it from slashdot.
Other Aspect Oriented Technologies (Score:5, Informative)
Since AspectJ is getting some attention I figured i would point out some other AOP resources
disgusting (Score:5, Insightful)
When will people realise that the most important thing in a programming language is to make it possible to reason about one part of it independent of another part? Most of the time spent developing a program is spent modifying code, not creating new code!
Unfortunately people don't realise this: they just want a way of hacking something existing into something different, cross their fingers and hope that it works when someone changes some other part of the system.
Sadly, it's not just AOP: some of the "usual" OO programming language features suffer this kind of problem too [micro-workflow.com].
Then again, maybe I'm completely wrong, and AOP has a sound theoretical basis and has been created by someone with deep understanding of programming language developments over the last thirty years... someone please reassure me!
Re:disgusting (Score:3, Insightful)
Actually, this is precisely what AOP seeks to do. By gather all the logging or DB transaction logic into one place and giving rules to the compiler for determining when/where to insert that code, you achieve a very clean separation of concerns.
The business logic writer doesn't have to know about logging or transations, trusting that the aspect writer it correctly specified. However, if the business logic writer comes upon a special case, that could be handled outside the general Aspect covering that.
Attempting to apply Aspects to Aspects can get a bit dangerous. But then so can recursion, reflection or any other powerful tool.
I think AspectJ is an interesting technology that you ought to check out before sneering at. Certainly it does have problems - my biggest problems with AspectJ spring from it not being tightly integrated with the language. When I used it, there were issues with debugging, building large projects and with non-hacker acceptance. With any luck, these have been dealt with.
AOP Resources (Score:4, Informative)
The Software Practices Lab [cs.ubc.ca] 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?
My take on AOP... (Score:5, Insightful)
Anybody who has worked extensively in Java has found this problem before. Cross-cutting concerns - you know, those systemic things that infiltrate their way into every module of your humongo-system, no matter how you try to partition it. Now, object-oriented programming, isn't that supposed to let you "blackbox" things so you can just abstract away such things and throw them in some "common" or "system" package and be done with it? Sure, you can. And you probably have. And I've done it too.
But these solutions can be suboptimal - for example, a project I once worked on had an Interface in the com.blah.blah.system package for logging, messaging, persistence, and some other features. These were always nasty pains in the ass to manage. I mean, some implementor of these objects existed everywhere in the system - if something changed fundamentally, or there was some insuffiency in the interface that was discovered, god forbid, you'd have to root around for hours changing code everywhere. Especially when exception signatures changed. Which eventually leads, in sheer frustration, to using Runtime exceptions everywhere, or declaring all of your "system" interfaces with "throws Exception". Ugh. Each solution seems worse than the problem.
Admittedly, problems like this can be solved with good refactoring tools and practices. But not always well. The exception issue for "system" or "cross-cutting" interfaces was one I've never seen solved well (again, I'm thinking of Java here, it's the language I have the most experience working in large commercial-scale projects in where this stuff is really important). If you are working on medium or small sized open source projects, or medium or small sized tools or desktop applications, you may never have come across these kinds of limitations or frustrations in sufficient numbers to justify looking into AspectJ/AOSD in general. But if you've worked on large enterprise software projects, I'm sure you can see that there is a need to "patch," but certainly not replace, the standard OOP methodology to address these kinds of concerns.
Hasn't CLOS had this sort of thing (15 years ago) (Score:3, Interesting)
If I remember correctly, in CLOS you can specify a method "foo", and then another method "foo" with the ":before" modifier that would be executed before the normal "foo" method. There is also an ":after" specifier.
Re:Hasn't CLOS had this sort of thing (15 years ag (Score:3, Interesting)
I did see a project on sourceforge to add explicit AOP to Ruby, perhapss making code more understandable, but of course one can hook methods without it
Re:Hasn't CLOS had this sort of thing (15 years ag (Score:3, Interesting)
Yes, and relational databases have had trigger methods before and after different SQL operations. You can define 12 triggers on a table in Oracle, made out of combinations of (before, after) (insert, update, delete) (for each row, for each statement). You code them in PL/SQL which is a fairly comprehensive language similar to Ada. Is AOP merely triggers for Java methods? Because you could do that already, by subclassing, overriding the method, and calling the superclass method within your own code.
Go read TAUOP (Score:2)
Go read The art of UNIX programming [catb.org] (online) NOW!. The author is ESR. Its an amazingly useful book. It cuts out all the hype and gives you a higher-level philosphical insight into effective programming.
Quote from the book:
Assemblers, compilers, flowcharting, procedural programming, structured programming, "artificial intelligence", fourth-generation languages, object orientation, and software-development methodologies without number have been touted and sold as a cure for this problem. All have failed, if only because they 'succeeded' by escalating the normal level of program complexity to the point where (once again) human brains could barely cope. As Fred Brooks famously observed [Brooks], there is no silver bullet.
Overlooked extensions to C (Score:5, Funny)
Instead of looking for radically new approaches in computer language development why doesn't someone introduce more colour into standard C. For instance we have if and while, how about adding verbs such as when, where or how.
Taking it further we might like to introduce more polite language into code such WouldYouBeSoKindAsTo or WhenYouAreReady. Imagine the code you could write...
when (time == "morning")
WouldYouBeSoKindAsTo (turn_on_alarm);
Alternatively we could convert C from English into, say, German. So if would become wenn etc. You could even mix nationalities. For instance if you wanted to be very forceful about a particular if statement you could use the German. If you wanted to seduce the code you might use the French.
Come on all it takes is some imagination. (Alternatively we could all just start using befunge [catseye.mb.ca]!)
AspectJ is a safe warm power drill (Score:3, Informative)
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.
Verity Stob (Score:3, Informative)
She also did a parody of our own Slashdot [ddj.com], which is absolutely f*cking hilarious.
I strongly recommend anyone who hasn't read any stob to go and check out the archives [ddj.com] and then laugh yourself stupid for half an hour.
Re:Verity Stob (Score:3, Interesting)
Nicely written, informative book review, too, by the way. Hope we see more of her here!
Speaking of weird things to like about Dr. Dobbs, does anyone else look forward to the PC-Lint advert/riddles every month? -- Asking that feels strangely embarassing, similar to asking "Does anyone else ever find that they've been talking to themselves for the last hour with the office door open?"
Maybe it's just me (Score:4, Insightful)
This has the feel to it that the programing methodology is becoming religious dogma, rather than a useful tool.
I've been getting that feel for a while now, as OOP languages start to compete on their "purity" or whether they're "real" OOP languages or not.
I've been programing "Object Oriented" since the 70's. In languages, like APL, that no one would consider "Object Oriented." Object Orientation is an abstract concept in itself that allows us to more easily abstract real world items into virtual objects and to manipulate them in a virtual world.
That's all. It is occasionally a very useful tool to have in one's bag of tricks. Sometimes it really doesn't apply at all and trying to force a fit just makes things labored and crude.
Trying to turn the entire universe of thought and logic into formal objects ( such as the number 1, which is most definately *not* an object), is putting the dogma before the cart, which then drags the poor cart anywhere the dogma wants it to go.
"Aspect" Orientation simply feels like a sect trying to break off from the Mother Church to me. This is not to say it may not be very useful, but that usefulness is needed because of doctrine in the first place.
Some things are objects. Some things are just operations or functions that have to be tortured beyond recognition if they're to be objectified. The less "pure" an OOP language the more *useful* I tend to find it, because it allows me to choose my methodology based on the problem.
Aren't there easier ways to add one and one and get two?
KFG
Why is the number 1 not an object? (Score:3, Informative)
In Ruby:
1.times { puts "Hello World!" }
Now there are other ways of doing that that are almost as readable and almost as useful but isn't that neat? What makes treating everything as an object even more useful is that you can treat everything the same way. You can always say obj.inspect and get something useful out of it. This is great when you're debugging something and wonder: "What the heck is this function returning?", whether it's an integer, a hash or a complex object, object.inspect will always work.
Java makes things confusing by having both primitive types (int) and object types (Integer), because in some situations you want to be dealing with an object, but the language isn't flexible enough to let you treat the object form of an Integer the same way you would a primitive int.
What I think makes Ruby so cool is that essentially everything in Ruby is, or can be an object, but it doesn't get in the way.
I agree that languages that are inflexible can be rough because they limit your options, but how is treating everything like an object inflexible?
Books (Score:4, Interesting)
What, like The Art of the Meta-Object Protocol [mit.edu] by the very same Gregor Kiczales et al, pub. MIT Press, 1991?
Like most things, AOP is only new if you don't know LISP.
Great Review (Score:2)
Hidden Horror Show (Score:4, Insightful)
AOP is useful, but not well suited to Java (Score:3, Interesting)
I think the reason there are so many 'huh? why do I want to do all this?' responses is that Java is not a language that lends itself to AOP, and that AspectJ therefore has to build this scary layer of 'pointcuts' and so on on top of it.
With a language that lets you assembly types dynamically, like Ruby or Perl, AOP is much simpler and more natural, so it's easier to get a feel for the benefits.
In particular I think Ruby is well-suited, although you do lose some type safety. There is a package called AspectR available, although you *could* do it all youself with mixins and the like.
A dinosaur writes: (Score:4, Insightful)
P.S. I don't dress fashionably either, prefering to save valuable beer money.
I bought it - its worthless! (Score:4, Interesting)
So I bought it, and I was excited when I began reading. Then I found out it was just a bunch of JSP and other then the first 25 pages, very little content. Now I admit I put it down a good 25 or so pages later and skimmed through the rest, but I was extremely disapointed in it. Instead I've been grabbing all of the ECOOP workshop documentation.
In the end, it was worth the money. No, not for the book, god no! But by getting me excited and reading the ACM Communication articles and then talking to my adviser about it. It turns out the editor for the AOP material in the ACM communications is a professor at my school, and even better is happy to let me help her out next semester (I'm extremely swamped now). So now I'm considering doing the thesis option on my masters. I'll spend the summer reading REAL material.
My opinion: AOP is awesome but the book is a waste of money. Here are a few good readings:
Alternatives to AOP [lancs.ac.uk]
Generitive Programming chapter [tu-ilmenau.de]
AOP publication [parc.com]
AOD 2002 workshop [iit.edu]
ECOOP97 [uni-trier.de]
Some thoughts from somebody who's using the tech (Score:3, Insightful)
In short, used judiciously, this is a very, very handy tool. Used indiscriminately, this is an utter fscking nightmare. And anybody who lets the project's junior-level coders work with this should be taken out back and shot. Repeatedly.
I hate aspect oriented programming... (Score:4, Funny)
Re:Where's this useful? (Score:5, Informative)
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
Re:Where's this useful? (Score:5, Insightful)
I'm not trying to troll here, but I'm afraid this might sound like it.... It sounds to me like the main selling points of AOP are that you don't have to design things well in the first place, because if you missed something, well then you can change how your objects behave without redesigning them.
The place where this wouldn't be true is with code that's part of the API or other code that comes packaged. I think that changing the behavior of this type of code sounds pretty dangerous to me - there's a reason that some data is kept in private and protected variables! Wouldn't you get into situations where you've added and aspect or a parent or some such thing, and in the process you access a private variable, and then you upgrade your runtime environment which changes the INTERNAL structure of the code that you hooked into (leaving the external API the same), breaking your code? Isn't that what code encapsulation is for? What I'm hearing touted as AOP's best feature is that you can break encapsulation.... Count me out.
Re:Where's this useful? (Score:2)
Maybe I'm misunderstanding your point, but can't this be accomplished via OOP?
override MyMethod() {
base.MyMethod();
}
Re:Where's this useful? (Score:2)
In AOP, you can decide to apply pre/post behaviors to a bunch of methods without needing to first create inherited classes, and then change the construction-calls ("new MyOverRiddenObject") to make those new classes.
Re:Where's this useful? (Score:2)
Or if you're writing in Obj-C. Using Obj-C, you can dynamically replace instance methods on the fly and call the previously defined method when you're done/before you start (or both, or not at all).
It's easy to do, and it's a dream if you need to patch a system, but it leads to code that is hard to debug/understand.
Re:Where's this useful? (Score:3, Insightful)
D
Re:Where's this useful? (Score:2)
Re:Where's this useful? (Score:2, Interesting)
Re:Where's this useful? (Score:2, Interesting)
Re:Where's this useful? (Score:3, Insightful)
And of course, INTERCAL has the 'COME FROM' statement.
Re:Where's this useful? (Score:5, Informative)
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!
A few better examples (Score:2)
1. Security processing...weave security checks into your code.
2. Transaction monitoring.
3. Automatic event propagation (get rid of those nasty JavaBeans listeners).
If, in a given situation, you call several methods in order, and that pattern is repeated across many other methods, each of those calls is a candidate for AOP, where you weave the calls in directly through pattern matching, rather than typing.
It can result in dramatically reduced code. It also _enforces_ behaviors (like when you forget to add that one line that does the security check).
Without AOP you are programming by exceptions, not by rule.
Re:Where's this useful? (Score:5, Informative)
Or you change one #define in one
Do they teach programmers anything useful these days? Sheesh.
Re:Where's this useful? (Score:3, Interesting)
The nice thing, then, would be a smart editor which is aware of aspects, and can draw flags on top of the source code you're reading so that the programmer is warned that an Aspect will be sticking it's nose in.
Even better, you could click those flags to apparently expand the aspect's code inline, revealing exactly what statements will execute when the function runs. Of course, this can't be reliably done in all cases, if the Aspects are something that can be toggled on/off as the program runs.
In that case, the editor might have to be pessimistic, and assume "an Aspect might apply here...". But that might not work well either. In the end, you need smart programmers, both writing the aspects, and using them.
Re:Where's this useful? (Score:5, Informative)
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.
Re:Where's this useful? (Score:2, Informative)
Re:Where's this useful? (Score:3, Interesting)
AOP is a very interesting notion in that it allows you to separate your concerns. Application logic, security, logging, transaction maintenance, etc, etc, etc. All of these things can be written separately but are then woven together at specific critical points. The result of good AOP programming is that your code is cleaner, and the guy writing application logic thinks only about application logic, not about persistence, caching, security, etc, which are all implemented as separate conerns and woven together later.
The real power is the ability to define this at runtime instead of compile-time, though. Imagine this- you write a generic caching and persistence layer for an application. You write this once. Then, at runtime, any time you want to apply this persistence layer's functions to an object, you just instruct the application (through a config file or some other means) to weave the persistence layer in with a specific object. Boom. Instant persistence. You could do this with any feature really, as long as you wrote each aspect generically.
This is a pretty extreme boon for certain classes of applications. Specifically, take any application that's modular or componentized. Each component can now have additional services dynamically bound to it. You can apply code as a policy over any activity...field modifications, method calls, constructors...etc. As a result, you can apply special policies to modules or compnents in your application without having to actually code them in to the component.
Other possiblities include applying advice to the constructor of Thread objects that checks threads into a registry on their creation. Now, every thread in the VM has a handle in this registry. If a thread flies off into an infinite loop, you can see the stacktraces of all the threads easily and have a better point to investigate from.
It's worth noting that the applications that really will benefit from this methodology...applications servers...are taking note of it. The JBoss 3.x series was written with a limited form of AOP that can only apply policies in limited ways to objects that implement certain interfaces. The next major version of JBoss promises the opportunity to leverage runtime AOP so that any Java object can have server services bound to it regardless of whether it implements an EJB interface or not.
Again, though, the power comes in in the ability to make these pointcuts at runtime. AspectJ, as far as I know, still doesn't offer this, so you can't dynamically change the aspect policies in your application dynamically. That makes AspectJ pretty useless for AOP in my book.
Then again...I could be talking arse. Here come the flames!
Re:Where's this useful? (Score:2)
AOP allows you to consolidate these portions of your program into a independent entities: aspects. An aspect will encapsulate a certain feature of your program into one location where you can easily modify, extend or replace it.
Wrote an application and would like to insert ACL checks for security prior to accessing data sources? Encapsulate this in an aspect. Maintain that aspect independently. If you want a version of your application with security, compile it with the security aspect included. Want a version without security, compile it without the security aspect.
Want to add security to another portion of your program? Where do you add it? Do you add it the security calls to the applicable methods of classes X, Y and Z? Or do you extend the set of join points to which your aspect is applicable? That is, do you add the security-layer calls all over hells-creation, or do you add it to the consolidated list recorded in your security aspect?
The more I look at AOP and the more I see, the more I think this will revolutionize development.