IT has seemed almost stable for few the last few years. Y2K, the euro, dot-com disasters, international terrorism and wars fought for dubious reasons have conspired to slow for a while the rate of innovation in our trade. Certainly things have got bigger (smaller) and faster and better, but nothing really new has made it big.
Despite this slowdown new things are still trickling out of the laboratories. One of the most interesting is aspect-oriented programming. It has been said that aspects are to objects what objects are to procedural languages.
"Object-oriented programming addresses common concerns," says Ivan Kiselev in his book Aspect-Oriented Programming with AspectJ. "That is, attributes and behaviours common among related entities are captured on top of a class hierarchy. In contrast, aspect-oriented programming deals with unrelated items, trying to modularise their common attributes and behaviours in a software layer that spreads across classes regardless of domain, thus increasing modularity of the software."
Aspects allow you to address cross-cutting concerns in a modular way. Cross-cutting concerns are aspects of a system that apply to a large number of otherwise unrelated classes. Logging is a common example, but any tiered architectural services layer is a prime target for aspects -- persistence, integration, XML binding.
They have the potential of reducing the cost of development and maintenance of your software, and also of increasing its agility -- its responsiveness to change, the cost of evolving your software to meet changing business needs.
Aspects are already available for Java in an extension tool called AspectJ. Support is available in the Eclipse free IDE and will soon be added to the incredible IntelliJ IDEA. Sun is looking at adding aspects and generics to the language in version 1.5, which is planned for release towards the end of this year.
Last time I spoke to Microsoft it said it thought aspects were cool, and it was working on a .Net implementation. Implementations for other languages are, I believe, in the works.
Hot on the heals of aspects is generics. C++ programmers have been able to create generic classes for a long time. It’s a feature used with amazing success in Stepanov and Lee’s STL (which must rank close to the top of the "Most amazing pieces of source code ever written" -- it’s completely illegible, and hideously complex, but it works).
However, the rest of us poor mainline programmers have just had to make do without such esoteric (and necessary) features.
Generics has two faces -- template code with parameterised types, and code generation. Sun is looking to add templates to 1.5, but the big area of interest is in code generation. In the Java world we have a few code generation tools as part of our development kit. We have had generators for RPC code for quite some time, and the same generator is used for the communications part of EJBs in J2EE, but now we also have a generator for XML binding -- it generates classes to model, read, and write XML-based on a schema, and a generator for Java data objects.
Code generators are becoming much more popular as mundane tasks are automated; for once the computer is working for us too. Of course, there is always a danger that something bad will be generated, but if it is you’re no worse off than you would be without the generator. The technology is becoming so popular that developers have started writing their own, project-specific generators for one-off use. This is a good move -- if something needs to change then it’s changed in the generator, and the code is recreated in an instant. This can save a lot of time (and cost) and make the system more agile.
Of course, the ultimate form of generation is executable UML. My old mate Steve Mellor was back in the country at the SoftEd software development conference pushing that tired old boat again. It may be the future of software development, but I just can’t get excited about it. Perhaps that’s because I’m a programmer, and see it taking away all of my fun. I think that it’s more likely to be that although I think the technology is exciting, I don’t actually want to do it myself. But if it takes over the world then that’s precisely what I’ll have to do because it’ll still need a programmer to do it right.
Or, perhaps, I think that translating a precise programming language into ambiguous boxes isn’t really an advance in the state of the art. Have you ever tried to convince someone that they should pay you to draw stick men? (For the CIOs out there, that was a UML joke.)