Some people, counting Richard Öberg, have come up with the latest in a long series of attempts at solving a long-standing OO problem – how to create classes that can take part in several different functions.
An example: Suppose you are a developer working for a telco. You may have heard about something called a “terminal”, which is… well… a phone. Sort of. Only it can do much more. No, really. A telco guy would know what I meant. (And, presumably, agree with me about the concise meaning of the word, which I can guarantee would not happen. Another blog post waiting to happen right there.)
If you have been persuaded by Eric Evans or Martin Fowler, you will quickly notice that terminal is a noun, and therefore may be a domain object. If you have not been persuaded by the gurus that a domain language or a domain model is a good thing, this post is not for you.
A terminal has several different natures. You can think of it in terms of a logistical unit – something that sits in a warehouse, gets mailed to a customer, then possibly returned.
It is also something that provides a dial tone to the customer. Note how a dial tone has very little to do with logistics. This is something separate, which happens once the customer has gotten hold of the terminal. Both of these functional areas are relatively complex behaviors which are going to need many lines of code to describe.
I can think of at least two more major functional areas terminals are involved in – and this is typical of a domain model. Your model is probably going to contain several hundred domain objects. A handful of them are going to be model hot spots which will, if you don’t watch your step, grow into spaghetti monsters with several functional areas smeared out over a single object. This is a problem on many levels. The simplest problem to describe is the sheer size of such a spaghetti mess – several thousand lines of code that is not one coherent unit, located inside one class/file is very hard to understand. Hard-to-understand code is not a good thing. It is a specialized case of writing your system using a single object.
Many have tried to solve this problem before. C++ uses multiple inheritance. AOP solves this problem, as well as many others. So far, no single solution has “won”. If you want to read more about these solutions, I suggest getting Filman et al, “Aspect oriented software development”. Oh, and while you are at it, Clarke/Beniassad: Aspect-oriented analysis and design might be a good companion book for when you want to draw your domain model out on a whiteboard. UML is not going to cut it alone.
Qi4j seems to be a rework of parts of AOP with this problem in mind. I haven’t been able to look at it much yet, but so far it looks more promising than AOP did. I think AOP has lost. I can’t really see any programming shop invest in teaching AOP to its junior developers if they haven’t done so already. The required “delta skill set” to use AOP is just too large compared to the benefits, and it is also “old technology”, which for some reason is ungood in the software business.
Qi4j looks like a much lighter-weight approach to this problem. I am going to be interested to see what happens to it in the coming months. I hope I can find the time to look much harder at it.
Geir
