This week I attended Expo-C, “a 3-day Software Architecture Conference” of which I went on two days. Software architecture is a dangerous word since it might imply so many things, from “oh so boring” to “a hoot” on the interest scale. Fortunately, this conference managed to place itself closer to “a hoot” than to “oh so boring”.
Rickard Öberg’s presentation of Aspect oriented programming, AOP, was truly interesting. I can only find one reference to AOP back in 2002 on this blog, so I think it’s safe to say that this was my basic opinion of AOP before the conference: nice ideas, but complex and will it work in larger projects? I have looked at AOP once in a while but never fully grokked it, and never used it for anything larger than testing that it works. And languages like Ruby and Python have made more impression on me.
Rickard’s presentation opened up my eyes for that AOP is really interesting. But then again, anyone who put this quote on the fourth slide has my full attention: “Inheritence sucks as a means of reuse”. That is a statement I can wholeheartedly agree with. The standard AOP example, the trace example, is nice and that kind of AOP (advice in AOP-lingo) is probably very useful (transaction management, caching, security and so forth are other similar functionality). But introductions, that is methods and data introduced to an object or class, is what really got me thinking. Rickard’s product, a slick CMS called SiteVision, used AOP (a home-brewn version) religiously, and it seemed to be a successful approach.
Another thing that Rickard stressed was tool support, and I do agree that tool support is crucial for the success of AOP. Back in 2002 AJDT was new, but now it seems to be a mature product, and it have some nice visualization features (I’ve just tried to create a simple aspect so far, due to lack of time).
The other main attraction of the conference for me was Rod Johnson who had one presentation during Tuesday, and a full-day tutorial of Spring during Wednesday. Web development frameworks is something that has interested me for quite a while, for some peculiar reason. I have only done two web projects, an e-learning system in PHP and a community in Java, and those were done during my university studies. Nowadays, my main interest, which I share with many in the blogosphere (at least the parts I follow), is in Ruby on Rails.
The conference was quite directed towards mainly Java/J2EE and somewhat towards .NET. I’ve been out of the Javaverse for a while so it was due time to get reintroduced. J2EE seems quite overcomplex and painful so I understand where the need for lightweight frameworks, such as Spring, spring from (bad pun intended). There is a lot of great ideas in Spring and it put a lot of emphasis on testability, to be non-invasive and to promote good design. The main tool to achieve this is, from my viewpoint, IoC/DI.
Inversion of Control (IoC), or Hollywood Principle (“Don’t call us we’ll call you”), is a pattern to loosen the coupling in a system. Instead of objects creating all the objects it needs, setters and constructor arguments are used to give an object the objects it needs. And (don’t know if it’s required or just recommended by the pattern) interfaces are used in preference of classes in order to further reduce the coupling. I think this is great in terms of testability: all external dependencies of an object is possible to configure/mock so you can test objects in isolation. Another great gain is that highly coupled designs become evident—classes with many external dependencies are easy to hide if the only way to notice the dependencies is to look at the source.
Dependency Injection (DI) is a technique to manage all the dependencies that IoC makes apparent. E.g. Spring figures out, aided by XML configuration and introspection, which objects that needs to be created for a certian class, create those objects and uses constructors and setters in order to inject the dependencies. Pretty neat to see Rod’s demonstrations of Spring and IoC/DI.
Singelton begone!
Spring also has its own support for AOP (working in a similar way as Rickard’s using dynamic proxies), and Rod pointed out that it’s a good idea to unit test classes without aspects since you want to test classes in isolation. Let’s say you have a security aspect, then it probably needs some setup in order to run, and that seems like a lot of work for a unit test and many thing that might go wrong and interfere with the tests, it’s more of integration test issue. That’s no problem in Spring since objects are just POJOs (plain old java objects), aspects are added by the Spring container so when you don’t use the Spring container you have no aspects. But how do you do that in e.g. AspectJ where the aspects become part of the bytecode? There is an infant project called aUnit, but that seems to just unit test aspects themselves in isolation. Or do you just use a different, non-AOP aware, compiler? Does anyone out there have any suggestions?
There were also a lot of other things in Spring that were very appealing. More metadata and code than Ruby on Rails, but if I’ll do anything server related in Java, I will certainly look at Spring.
One thing that I thought of while listening to all the interesting stuff about AOP, IoC/DI was how this would translate into the Ruby/Python world. The concepts apply even there, but the programming languages are more hackable than Java, thus it ought to be eaiser to achieve. There are probably many different approaches in the Ruby/Python world that I will have to look into.
Great conference! Would gladly come back if they manage to get as good, or even better, speakers!
Two comments