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."
When I was first starting out in programming I read Booch's OOA&D, and spent the next while thinking he was one of the smartest people on the planet.
;-). But I'd hoped that Rational was a beacon of excellence in an industry full of buggy crap. I guess that's too much to hope for right now. Maybe in another 30 years when "software engineering" has become a _real_ discipline...
However, working with Rational's software has tainted Booch's name for me. After dropping the large amount of cache for the entire suite, I think many people realized it would have been better to spend the month or so of man hours getting open source tool x, y, and z up and customized for bug tracking, requirements management, etc; rather than dropping tens of thousands of dollars and spending several months with Rational eating data and hoping the next emergency patch will fix our problems.
I'm well aware of the difficulties in developing large scale software, and I'm not suprised---I've worked on software that was done similar things
I was very impressed that the first edition of OOA&D had examples in CLOS, Smalltalk, C++, and Object Pascal (if I remember correctly). But I tend to think that when he publishes his next book it will be with examples in VBScript (probably on extending various MS Office products to interact with the Rational Suite, while alienating UNIX users).
Don't blame me, I get all my opinions from my Ouija board.
I think "disruptive" in this case means it may be another chance for gurus to promote their software and training as a solution to the problem that customers are dissatisfied with the "quality" of software, and software development schedules are too difficult to predict and control.
From "AOP" experts, I expect to see quite a few descriptions of obvious problems, and some hand waving "solutions", such as design/development "methodologies", "modeling languages", and "patterns", which are not as disruptive in the real world as they are in the academic papers and the product literature.
Hmm, you are fast with your judgement. Too fast and obviously you missed the point and didn't do your homework.
AOP is not about Java but rather a total new way of modeling & programming (obviously the general idea was lost on you), it was just implemented on top of Java as a proof of concept. The people who implemented AspectJ (one of the handfull of aspect oriented languages), made sure that it works well, integrates nicely with the language.
Indeed, AspectJ evolved from just a prototype language a few years ago to a production ready compiler and toolset. The very reason it was created was to allow for industrial validation of the ideas that are behind it. The inventor of AOP (Gregor Kiczalez), figured that in order to do so you needed more than just a prototype language.
BTW. the journal side of things is taken care of by the ACM. They recently had a special issue of Communications of the ACM on AOP. Also nearly any conference on OO systems (e.g. Ecoop, OOPSLA, ICSE) in the past few years had papers on AOP issues (validation, language and compiler issues etc.).
If you want to learn about AOP, look at the tutorial and language spec on aspectj.org. Also be sure to look at the examples they provide.
Jilles
upon a bit more research, I'm convinced that this could be a usefull extension to OOP in alot of situations (mind you I'm still not 100% convinced that OOP is the 'one true way'). I don't think its the ends within the means that its made out to be in the articles though.
I'm not entirley 100% convinced its really worth *that* much, every example he gave for OOP leading to bad design, well, was *bad design*; so I think I'll have to see a bit more realisitic comparison before I jump on the bandwagon.
I think a better description would be Event Wraped Objects, it seems more realisitic (though perhaps less easy to market).
Anyway, this is an interesting peice of trivia to have, I don't think its a end of the world type upgrade, but if it does catch on it should take alot less time to beat into my head than OOP did, considering all it appears to be is event wrappers for program actions.
I live in a giant bucket.
(* Publishing you work in popular journal instead of specialized magazine. Word's like "higher productivity, improved quality" instead of clear evolution of new ideas. *)
Those kind of claims tick me off also. Why don't they simply say that this is a new way to do/look-at things that deserves further exploration.
To go barging around claiming that it will make everything cheaper-better-faster is disingenuine. It is waaaaaay premature for that. There are a lot of complex tradeoffs in software engineering. Improving one thing often can hamper others that promoters conveniently forget to mention/check.
I don't mind experiments, as long as they are labeled as such.
______________________
oop.ismad.com
Table-ized A.I.
Maybe they should call it Event Orientated Programming, sound more like functions can capture events and execute on the context of the event. You could hook this in to C++ (tho not very cleanly), but it sounds sort of similar to what QT's moc does to QT C++ code.
With stock Java, you can inspect a particular method and know almost exactly what it does. It's a lot of work; you have to examine:
- the instructions inside the method
- the arguments to the method
- the instance variables and the methods of the containing class
- the instance variables and methods of the parent classes
- the contracts of any classes you have to be using
It's annoying to do but the lexical structure of the language makes it clear where you have to look. The only exception is when derived classes override methods in the class you're examining. (And this is a problem with every class-based OO language out there.) If the method is "abstract", though, at least you have some indication to look elsewhere.AspectJ messes this up badly, because you can no longer tell what's going on by tracing code. To understand the behavior of a method, you have to do everything you did before, plus know and understand every single Aspect defined for your program, since any of them may change any of:
- The behavior at the beginning or end of your method
- The behavior at any function call in your method
- The parent of the class
Aspect weaving is useful---it makes up for some of the lack of power of Java---but if Grady Booch's hype machine is successful, he'll sell a lot of books, people will use a lot of Aspects, and no one will be able to tell what is going on in their programs.