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.
I think you are missing what the paradigm suggessted in AOP is; it is a concept that is recognized in the OOP community as "Separation of Concerns." You can do separatin of concerns today if you can agree on a framework and are quite explicit about it. It is much like Object Orientecd Programming and late binding/polymorphism, you could do all of those things in the previous generation of languages without language syntax. Heck OOP is even done today in the GTK widget set.
The difference is that when the concepts are supported in the languaes it is (a) orders of magnatude easier for the developer proficient in those skills to do it and (b) it allows for an order of magnitude more developers to grasp the concept and exploit it.
Java's EJBs are a current example of doing separation of concerns (SOC) without language bindings, in fact it it explicit in the original specification. The business rule writer doesn't need to know how the deployer deploys the EJBs and they don't need to know if it is an Oracle Database or DB2 or an IPlanet directory server serving as the persistance for the objects. As long as they follow an establised set of rules, such as business rules don't create thread objects and the deployer respects and stores all of the data that it is told to store it works. Then the person writing the business rules doesn't need to know about load balanceing and clusering and the deployer deploying into the load-balanced and clustered environment doesn't need to know a rats ass about the business rules or any other parts of the workflow for that EJB. Thus the people who do procurement rules procure and the people who know scaleability scale. In fact, the only time that the business rule guy and the deployment guy would need to talk is at the company christmas party, and they don't even need to know who they are.
Now we can look at how SOC is done in EJB and that is generally the same style OOP was done in C (not C++). There was a lot of infrastructure and practice that had to be followed that was not enforced or explcit, and the means of doing them were often different from project to project and even module to module within a project. When C++ came along it was much easier to establish how you denote inheretance for polymorphism and when a functon should be virtual and thus bound late. AOP languages like AspectJ are providing the means to provide for these "aspects" (I don't like the name either) much as C++ did for the OOP practicces. Making it more accessable and maintainable.
I must a gree with Booch, AOP will be affecting the future of software development as dramatically as the OOP concepts did. And if one doesn't keep up come 2010 you will be maintaining old payroll programs on a low paying contract rather than leading or managing a team on new software development in AOP.
--Shemnon
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.
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
(* 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.
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
Yeah, I think they might have more success if they could describe this is simple language.
Here's what I get from it, translated into English, and sprinkled with some object-oriented terms.
Start with some Java code. This thing lets you search through the classes for method calls. For example, you could search for methods whose name begins with "Draw". Using these tools, I can attach event handlers to every call to these methods. My event handlers can run before and after each method call.
An "Aspect" is like a class, except it has really confusing syntax. The Aspect tells the compiler which methods to look for and what events to attach to them. Besides methods, it can also look for things like constructors or property setters.
An "Aspect" can do some nifty things. For example, if a class B inherits from C, it tweak it so B inherits from D instead. Also, it can add things (methods, variables, etc.) to a class or interface. Or it could change what kind of exception a method throws.
Then he talks about a few more advanced things, like how many instances of an "Aspect" I create. It could be static so only one instance exists, or I could make a new instance for every method I attach to. Or something in between. Also, an "Aspect" can show warnings and errors at compile-time.
Donate background CPU time to fight cancer.
and unsurprisingly the inventor of AOP (Gregor Kiczalez) also wrote a book on the meta object protocol (meta programming in CLOS). It's funny how people try to dismiss stuff by comparing it to stuff they do know. Aspects are of course easy to implement in Lisp (just as most other language features we know). The original, quite interesting, paper on AOP at Ecoop '97 even used CLOS for the examples. Lisp is a very powerfull language, however it is also very hard to use.
Kiczalez realized that if he'd stick to lisp, AOP would never work because ordinary C++/Java programmers would never be able to understand it (just like they never grasped meta programming, reflection and whole bunch of other advanced language concepts). Hence he made an implementation of AOP based on Java. One of the design goals was interoperability with Java so that the transition would be as easy as possible.
Now the difference between the visitor pattern and AOP is that the visitor pattern affects the design of your program (i.e. the places where visitors are used must explicitly call a visitor) whereas the usage of aspects is transparent.
Jilles
The confusing thing about AspectJ is that it is really not Java but rather a different language that happens to share a lot of the syntax and is able to compile to bytecode (just like e.g. Jython).
Currently the compiler merely does some preprocessing and then uses the Java compiler but the long term plans are to create a separate, incremental compiler (to improve performance on large projects).
It is also worth pointing out that there's a difference between AOP and AspectJ. AspectJ is one of the many aspect oriented languages. Other examples include IBM's HyperJ and Karl Lieberherr's Demeter Java (do a search on google if you are interested).
AspecJ happens to do most of the weaving statically but this it could just as well do it at run-time. The only problem with that is that this would affect performance since you need to do all sorts of reflective stuff in order to make it work.
The best way of describing what AOP does is to think of your OO system as a graph of objects calling each other. Aspects insert functionality on the paths in this graph that augment e.g. return values or exceptions or introduce new data.
You could for instance insert an aspect that would simply count all accesses of public methods (not particularly useful but the point is that you can). In order to that you would need a static aspect (i.e. all insertion points get the same aspect instance) with an integer and some increment functionality. In addition you would write a pointcut (i.e. a pattern identifying insertion points in the graph) that gives you all the public methods. The AspectJ compiler does the rest.
The whole point of AOP is that counting the public method accesses is a concern that is different from the other functionality in your program. More importantly, in a regular OO program it is a crosscutting concern since you would need to insert functionality in each public method to make it work.
By making it an aspect you separate the concern from the other concerns that your program addresses. Should you for example discover that you would need a long rather than an int, you only have to update the aspect rather than each public method in your program.
Well designed OO programs also exhibit some separation of concerns. Typically you will find stuff like design patterns being used to do so. The price you pay is a more complex design. AOP potentially offers you a cleaner and easier to maintain solution than design patterns. However case studies will need to proof this (this is the primary motivation for creating AspectJ).
Jilles
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.An aspect is a property of a set of classes or methods.
Hu?
The simplest aspect is a logging aspect:
,,on enter method``
System.out.println(method.name() + " entered");
,,on exit method``
System.out.println(method.name() + " left");
Now say:
,,all classes in package foo use aspect enter method and exit method``
A aspect weaver (somthing like an OO object code morpher) now injects the two aspects into all methods of the package foo.
Aspect oriented programming is about "grasping" ideas, code fragments, which are smaler than methods but can be regular expressed (like a regular expression).
Similar concerns are described in one aspect, its like a class consisting out of code fragments.
Then you write your classes without repetitive enter/exit -- or other -- patterns in their methods.
Finaly you weave classes and aspects together into an executeable.
There is a somewhat similar new way of programing: subject oriented programming.
See "hyperj" at ibm.aphaworks.com.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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
Wrong wrong wrong. It did not stem from Java and the term was coined by Gregor Kiczales, who is a professor at the University of British Colombia. Arguably the first AOP system, composition filters, was invented at the University of Twente. There have been dozens of papers published by various groups from around the world, a bunch of AOP workshops and conferences, and there has been a Communications of the ACM Special Issue on Aspect-Oriented Programming. See aosd.net for links to conferences and papers.
--
Robin (who is doing his PhD on aspect-oriented programming and object databases, and will post more later).
Female Prison Rape in NY
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.
Those are old buzzwords. "Aspect" is a newer one