more rant about aop
I’ve had a minor obsession going with aop lately. Maybe it’s that I think there’s something valuable there but can’t quite pinpoint it, or maybe that its that it’s getting way more attention than it deserves. But as I read articles, blogs, introductions, papers, etc… I’ve noticed one consistent thing that always kicks my blood pressure up a notch:
Nearly every discussion of AOP contains the assertion that classic OO techniques are insufficient by themselves. And almost without exception, this assertion is made without any backing evidence whatsoever. I’ve been searching to find a single problem in enterprise software that cannot be solved with pure OO methods (and without scattering), and I can’t find a single one. If you are going to make this type of statement I think you should be prepared to defend it.
The primary example that AOP advocates give (ad nauseum) to demonstrate the usefulness of AOP is logging. As a developer of enterprise and consumer applications, I see a lot problems with the state of the art, but I have never seen a system where the scattering of logging code was a significant problem. Software researchers should start with problems the industry is facing, and develop solutions. The AOP community appears to be doing the opposite.
In my experience, there are two types of scattering that hugely affect enterprise applications. The first is the scattering of domain logic throughout the system. This is due to the lack of a coherent domain layer. Although everybody says you’re supposed to isolate your domain logic few people actually do it. (Especially in the Microsoft world) If you do build a rich domain layer you are likely to find that you have a new problem. An explosion of dumb domain classes as you add new types of objects to the domain layer for everything in your model.
It turns out that in enterprise software the main source of domain complexity is not the logic, but rather the structure of the domain objects themselves. Ralph Johnson has a paper where he describes an insurance client that would have needed 10,000 classes in their domain model if they used POJO’s, (or PONO’s) to implement it. Of course they were bright enough not to write 10000 classes. They created a dynamic object model that let them encapsulate the common functionality of those 10000 different things. They did not blindly map domain construct to classes, instead they created a framework by which they were able to dynamically construct the necessary types of objects from a few basic building blocks. If you’re building enterprise software, that’s how you fix the domain scattering problem. It will also enable you to distrubute new types of objects to client processes without redeploying. AOP, at least as far as I can tell, won’t help you do that. What’s more, if you do build a dynamic object model, its easy to add AOP-like event functionality using conventional techniques.
After you have your domain model cleaned up, the second problem that usually comes up is the stuff outside the domain: User Interface code, Networking code, Data Access code. It’s not part of the business requirements your trying to fufill, but you can’t build the system without it. You’re going to make tough decisions in all three of those areas. For the UI, browser or smart client? For the DAL, SQL Server or Oracle? for the Networking, HTTP or TCP, asmx or WSE, etc… There’s a good chance you are going to make the wrong decision for one of those three, and you would like to be able to change your mind without having to start from scratch.
The key here is simply to create independent subsystems for the UI, DAL, and Network layer, and let them each depend on the domain layer, but not on eachother. Doing this well is an advanced OOP task, but an entirely manageable one, and it doesn’t need any new language features.