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.
Adding more keywords to Java (yes, Java programmers paid 20% better) without much reasoning (you can easily do the same things without new keywords). All ideas realized was sure met by language designers and was sure discarded for simplicity. Modulizing? Module structure cannot be defined by language itself unless language includes project management. Java don't.
Publishing you work in popular journal instead of specialized magazine. Word's like "higher productivity, improved quality" instead of clear evolution of new ideas. I don't like it. Point.
The entire wildcard thing looks like it could really create some problems. Who knows what that will expand to? You certainly can't tell by glancing at the code.
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.
Let's break down parts of our problems in a functional way. Then, let's group our functions together into modules, so that functions in a module are related.
Then, let's call it AOP and hope the old Modula-2 programmers don't notice.
Can someone explain exactly what is new about AOP?
If tits were wings it'd be flying around.
spot the buzzwords and impacts and marketing hype: starting with part 1
software systems, concerns, crosscut, Object-oriented, concerns, invasive to implement, tough to understand, difficult to evolve, aspect-oriented programming (AOP), of crosscutting concerns, facilitates modularization, crosscutting concerns, easier to design, easier to understand, easier to maintain, higher productivity, improved quality, better ability to implement newer features
(done paragraph 1... this isn't looking promising)
"goal, concept, or area of interest" (to be fair that was a definition), core concern, system-level concerns, "transaction integrity, authentication, security, performance" (only because they were placed there to impress PHB's), crosscutting concerns, implementation modules, "systems that are harder to design, understand, implement, and evolve."
(end paragrph 2, slightly better, only half the words were buzzwords...)
separates concerns, modularization of crosscutting concerns.
ok, I think you have goten the point by now, attempting to finish the document.
If anyone knows something non-buzzwordish that has to do with AOP can you please post it? Since it appears to have stemed from Java and was never part of academia (a fact that kinda scares me), real factual sources are a bit lacking from google searches.
I live in a giant bucket.
From what I've read of "Aspect Oriented Programming", it is just a reinvention of multi-dispatch methods or a language-level support for the Visitor OO design pattern. With multi-dispatch in a language like Lisp/CLOS, a single function call can (optionally) implicitly call your logging function, a monitor synchronization function, a security check function, etc.. before or after calling the "real" function.
Funny how so many new programming fads are simply reinventions of old Lisp features because the new programming environments (like C++ or Java) need clumsy workarounds.
cpeterso
It looks worth a second look, but are there any articles which explain the concept in a more clear and objective manner? I have been to the aspectj site, parc/aop and aosd sites, to no avail - the articles seem a little more intent on selling the concepts rather than explaining them.
I dunno, but my mental buzzword filter kicks in reading articles like this. Or perhaps I am getting slow in my old age...
My main worry these days with new technologies is that many organisations and developers use them for namesake rather than practicality - they create a vicious circle where the job market becomes disproportionately biased in favour of technologies that are used less often but considered to be "important". EJB & XML spring to mind here - not that they are necessarily bad technologies, just that they are often over-applied just as a point-scoring exercise. And in many companies (not mine), employees are effectively rewarded for spending their time at work reading up on new technologies so that they can b.s. about them... generally leading to a bad work ethic centred around buzzwords rather than objectivity. Not that it bothers me, they are welcome to their inefficiency!
So, any links to more informative sites would be helpful, particularly one describing how it can improve productivity, quality, decrease development costs, or indeed, if it does not and why.... so far I am curious but unimpressed!
(* The entire wildcard thing looks like it could really create some problems. Who knows what that will expand to? You certainly can't tell by glancing at the code. *)
I imagine that it will end up like most of "one command does magic" coding ideas: the granularity is too large and there are too many exceptions to the rule to make it work in the real world.
Now:
*
2004:
* {unless x < 5}
2008:
* {unless case:
a: bar < 5 and foo
b: * > 9
c: * in (u,v,w)
}
2012:
* {unless class foo
method a {......}
method b {......}
method c {......}
}
Etc....
Gee, I don't sound too skeptical, do I?
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.
Good application design is good application design is good application design...
What he states as separation of concerns is good and all, but misses an important point-- clever modularization or a program and good design allow reasonable separation of concerns while still allowing the developer flexibility in how each module handles those concerns.
I don't like his description of AOP because I think that it takes good design principles too far and makes them inflexible. My experience with large applications has taught me that reusable code for common functions is very important, but so is control on how those functions are implimented in every case.
(And no, I am not generally an OO fan either because I think that in most instances, it makes the application more difficult to impliment, but there are HUGE exceptions to this, and I use it where I see fit. I often use proceedural programming on my core engines, structural programming where the data complexity becomes slightly higher, and OO when an abstract interface actually allows me to impliment extremely complex object models.)
LedgerSMB: Open source Accounting/ERP
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
It seems to me that the examples given could be addressed by creating appropriate libraries or classes.
//code for validating input goes here
With AOP you dont write the network optimization into every module, the computer does it for you. You just create a line of code that says "apply the network traffic optimization to all of the objects." While it is transparent to the programmer the develoment tool does in fact add the code then compiles it.
This is just one example. Can anyone confirm/deny this? If this is right I can see how it would save time and reduce confusion, making it very useful but it sounds like a lot of excitement over a small improvement to OOP. More like OOP++ than a new methodology.
Let me restate so folks can adress my comments properly
1)AOP seems not to change the final product before compilation. It does add a step before compile time, which is called weaving. Weaving seems to add required code to ensure that all aspects of each object are addressed properly.
2)AOP simplifies design and coding by placing the calls to the appropriate procedures or methods in the called procedure or method
***EXAMPLE*** (please excuse my pseudocode, my pascal is showing)
FUNCTION validate_input
{
ADD_THIS_FUNCTION_TO (object1,object2,object3);
}
FUNCTION object1
{//gets numbers}
FUNCTION object2
{//gets strings}
FUNCTION object3
{//gets passwords}
My understanding is that before going to the compiler AOP would process the code and weave in the FUNCTION validate_input simply by adding the code in the right places in oblect1, object2, and object3. a)Am I right? b)if not (if, for instance, aspectJ does something different which is more customized to AOP) would this have a similar effect?
While this example is truncated and perhaps illegible I would appreciate any feedback as to whether or not it is on the right track.
More food for the mill.
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
Hi,
I'm by no means an expert at AOP, I've never used it, only read about it. But from what I understand I don't think it's that great.
AOP seems most similar to the OOP approach of 'composition', that is, creating larger, more feature-full objects out of smaller sets of objects. I don't see any other fundamental difference between AOP and composition. If there is please enlighten me.
The problem I have with AOP (and regular OOP Composition doesn't fare much better in this regard) is that designing a system with a number of small distinct components seems like a good idea. It still seems like a good idea when you use composition to create larger objects with more functionality out of the smaller pieces. The point where AOP breaks down is when you want to use the AOP objects in some even larger AOP creation. The point when software development gets to this stage is usually well into the implementation and maybe after it is in production. At this point it seems to me like you're back to dealing with all the original problems that AOP was meant to help with (spaghetti-like code being the most significant).
Is there really more to AOP than what I've been able to deduce?
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.Assuming I was not overrushed or outvoted in my technique, I find my code far easier to read than other people's code down the road. That is because I know how I think.
Software Engineering is *mostly* about psychology, and not math nor machines nor magic paradigms.
Table-ized A.I.
first time i read the article i thought - dontcha identify yr concerns when you do your use case analysis and see the verb "log" cropping up and then factor out all that function into a class responsible for logging? IWC, i did not really see the value. then when i re-read and looked at the code examples i thought - if you develop for concerns, maybe there is more extensibility in the source because it is concern-aware? would that give you more refactoring elbow-room during the lifetime of the system?
The tigers of wrath are wiser than the horses of instruction, but they eat more steak.
I consider neither language to be ideal. However, I am pleased to see powerfull language features gaining acceptance among ordinary programmers (few of which ever use lisp). One of the reasons Java is so popular is that it provides some interesting features and is simple to use at the same time.
Syntax easthetics is of course matter of taste but many would argue lisp is quite insane with all its parenthesis. The Java language was cleverly designed to look like C++ and be as clean as Pascal. Perl on the other hand evolved from a simple scripting language to an everything and the kitchen sink language. During its evolution nobody bothered to pay attention to the syntax (other than to stay as close to the more or less quick & dirty syntax of the earlier versions of perl).
I would say that being able to do something in lisp and practice of doing something in a certain way in lisp are two different things. AOP can be implemented rather easily on top of lisp but I don't know of many projects where lisp was used in an AOP style of programming.
Jilles
the AOP thing is a good design solution for a highly decoupled kind-of miasma of objects when nothing happens and then events do? where there is less of a logical use-case type of path, and state is more critical than state transitions.
but then, if you had that sort of a system, there are a number of patterns that would do most of what you want - does AOP look like the retrofitting an event paradigm onto a more workflow type collaboration of objects?
The tigers of wrath are wiser than the horses of instruction, but they eat more steak.
I would very much like to see how you do this with Common Lisp macros.
A very long time ago, someone suggested a programming construct called "COMEFROM" that allowed you to declare you code to be called from somewhere else, regardless of whether the caller wanted to or not. That was a joke. Obviously no sane person would suggest being able to write code that gave you no clue what other code was being invoked, right ?
Well, apparently, this is exactly what a supposed expert on design is now suggesting. Code that executes on arbitrary conditions. Stuff that executes before and after your methods that changes their results. I can only conclude, given that Booch is clearly not joking, that this is a conspiracy to lower the quality of software and thereby drive more poor benighted, deluded souls into the arms of the Ration Unified Straightjacket and mechanistic OO design methodologies.
I can see the goal. However the proposed mechanism is basically ghastly. It allows you to stick extra bits of invisible code in all over the place that get executed without anyone even realising they're there. Its a similar problem to operator overloading, or C#/Delphi's property mechanisms, only much, much worse.
To make it work better, something has to be done to reduce the power of the mechanism. Say, preventing the "apsects" from having any having any side-effects that affect the code that triggers them.