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."
Betty is visiting.
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.
dropping the large amount of cache for the entire suite
I assume you meant cash
Quack, Quack
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
Even more interesting that, even though every imaginable language feature already exists in LISP people are constantly implementing them in other languages.
Perhaps it's because the other languages have a syntax that makes sense to normal humans?
It's a bit more sophisticated than that. The AspectJ compiler does whole-program analysis to insert the cross-cutting code, which would be much more difficult in CLOS. It also inserts the code at more places than :before :after and :around various functions.
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.Well thats a funny post. Guess noone reads this deep into a thread. I can see where you're coming from but even just OOP techniques degenerate into a mess of spaghetti in the real world. Every new programmer comes along and looks at the code they've been asked to fix and goes "this is shit!". What you want is a programmer who will fix it with the minimum of disruption (rather than spending 1 month rewriting it for his clarity, when two months later another programmer comes along and goes "this is shit!", repeating ad infinitum). The only things problems you don't get spaghetti in are small ones.
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.
If someone can give me clear one-sentence answers to the above two questions, maybe there is something to AOP.
And then Java 2 introduced (kludged in) extensive reflection support to support Java Beans, so Java programmers started to have to understand it.
Basically, in 10 years time, the Java/.net community will have reinvented lisp, but with insane syntax. Just like Perl has already become a lisp-with-insane-syntax...
So Java is a big plot to slowly wean people to Lisp ???
The above may be presented in a trollish fashion, but it's true. Aspect-oriented programming is a proper subset of programming in Lisp (in fact, the original aspect-oriented stuff used the power of CLOS's MOP to work)
All AOP is is bringing to Java something that Lispers had years ago, and doing so in as hypey a way as possible.
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 agree it would be more difficult within CLOS, but CLOS is only a subsystem of Common Lisp. A few macros would be a much better (and ridiculuously easy) way to write an aspect-oriented system.
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.
AOP and AOSD (Aspect-Oriented Software Development) is about explicitly addressing crosscutting concerns ("aspects") during the development cycle. In other words, and along the lines of Object-Orientation is more than just programming.
A concern is term crosscutting if it cannot be well localized, i.e. if it cannot fit into a single modular unit. Examples of crosscutting concerns include synchronization, scheduling, fault tolerance, error handling, etc.
Please do not forget that AspectJ is merely one of the several available technologies, and one that addresses aspects (crosscuting concerns) using a linguistic approach. Other approaches include reflective techniques, and aspect-oriented frameworks, and combinations of the above. You may take a look at http://aosd.net as a starting point.
I will try to address some of the criticisms about the article as well as some other misconceptions:
Obscure syntax of AspectJ: This has nothing to do with AOSD as a concept, but with the particular technology. There are plenty of other languages, including AspectC++, as well as a lot of domain specific aspect languages. In other words, there is and there should be a difference between a criticism on AOP and a criticism on the AspectJ language.
Gregor Kiczales and Xerox: Gregor is not the inventor of AOP. The inventor of AOP is Cristina Lopes with her PhD thesis (Northeastern University, 1997). Gregor was Cristina's second advisor as at the time she was an intern at Xerox. Cristina' advisor was Karl Lieberher the director of the Demeter project at NEU and the main investigator of Adaptive Programming. Cristina built two domain specific languages (one for synchronization, and one for coordination) to be used in distributed programming. The motivation for the invention of AOP (AOSD) is a family of well-known problems associated with conflicts between synchronization and reuse known as "inheritance anomalies". A large number of research proposals have addressed this problem, separating synchronization from the main functionality, but leaving it in the same class (e.g. ESP). Cristina was the first to propose a complete separation for a higher level of reuse and the provision of adaptability. Since then there have been a large number of AOSD proposals using different technologies.
AOP can be done with libraries. You are missing the point of separation of concerns. With libraries you indeed achieve reusability of code but you cannot avoid what is termed "code tangling".
AOP to replace OOP. This is simply not true. In fact, AOP is not bound to OOP, and there are plenty of papers and research work in AOSD and functional or logical, even procedural programming. One example is AspectC (University of British Columbia, principal investigator is Yvonne Coady) that addresses (operating) system design.
To conclude, OOP has done and it still does a great job. However, for certain problem domains and in complex systems (e.g. concurrent and distributed systems) AOSD can be used in conjunction with OOP to address the *remaining* tangling of code (concerns).
If you want to learn about the principles of AOSD, the JavaWorld article does not provide a good introductory treatment in my opinion. I have been doing research in this area since if first appeared (1997) and I didn't like the article but then again this may also be a matter of approach to introducing the main idea. A better treatment that talks about the concepts and about the major technologies (including AspectJ) would be "Generative Programming; Methods, Tools and Applications" by K. Czarnecki and U. Eisenecker (Chapter 8: Aspect oriented programming). Please bear in mind that the book was written in 1998 and the technologies have evolved since then but the main idea is the same.