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."

Comments

Booch's own company is hardly a poster child...

[Raskolnk]

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.

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 ;-). 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...

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).

Re:Don't like it

[shemnon]

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.

Re:Don't like it

[jilles]

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.

Re:I've got a great idea

[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.

Re:AOP is a reinvention of multi-dispatch function

[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.