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
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
Sure,
You have your regular OO program. Only you don't do the usual thing of littering with duplicate functionality for e.g. synchronization, persistance, security. This kind of code is what makes your program complex and generally requires rigid design rules in order not to blow up in your face. What AOP does instead is separate this kind functionality from your OO program into what is called an aspect.
Aspects consist of code and a pattern defining where this code is to be inserted in the OO program. This process is referred to as weaving.
Take for example logging. All large projects need this. Imagine you could just write down: for all public set methods in package X Y and Z: prior to execution write the name of the method that is called to the log. In aspectJ you'd define this functionality in a few lines of code whereas in your average OO language you would need to edit each and every public set method. In addition if you'd add a new public set method somewhere you would need to add the functionality manually. You might forget, introduce bugs (well, maybe not in logging).
Now logging is just the most simple example of an aspect. There are many more and the people at aspectj.org do a much job of explaining it than I can. So, go have a look with an open mind. Download the compiler, try the examples and use your imagination.
Jilles
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.