Monkey Code
There's another MDA discussion at TSS, and it has prompted this longer-than-usual post on Monkey Code.
This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.
I couldn’t agree with you more. Creating those umpteen classes each with umpteen getter and setter methods is plain silly, because the responsibility of each and every one of them can be summed up as “this class holds a set of name-value pairs and provides access to them”. We can easily do the same thing with only one class, e.g. a Tuple class.
Thanks for your comment. I’d like to point out, though, that a generic (not generative!) solution has its own set of problems. I remember load of performance problems in projects that put attributes into a hashmap in the objects where they were then accessed with something like getAttribute(“SomeAttrib”) instead of getSomeAttrib(). This is an order of magnitude slower at the minimum. It’s a good idea, as always, to aim for a balance between generative and generic solutions in your application.
True, getAttribute(“SomeAttrib”) is slower than getSomeAttrib(), but it still much faster that a database call or the generation of a HTML page. I have never found it to be a bottleneck. Generating the code is a happy medium in some ways, but I find it leads to the need to generate more code, which leads to the need to generate more code, etc… Although I have found successful ways to use Java reflection to mix the two paradaigms.
I’m not condemning this on principle: Whether the better approach for a given project is getSomeAttrib() or getAttribute() depends on the usage pattern. The getAttribute() way works very nicely for UI patterns, where you link an attribute name to a control. It sucks if you have complex algorithms that access the attribute multiple times. Combining code generation and genericity/reflection allows you to wrap one by the other - i.e., either have getSomeAttrib() call getAttribute(“SomeAttrib”) or the other way round. An MDA approach allows you to swap one for the other even when your application is done …
Yup. And it also works well for many classes of data processing applications as well (data entry, ETL, etc), because 90-95% of the attributes are just traveling from place to another. There are few reasons to call getAttribute() on them. However, I would probably not use the generic approach in a real-time control system. How does MDA allow you to swap implementations after the application is done?
The basic idea is that you can separate your object model - let’s say including the classes Customer, Address, Contract, Order - from a decision like whether you want to have attribute methods use a generic or a typed/named approach. Which of these approaches you use is specified in template rules; these are applied to the object model, yielding either one or the other result. Since you can re-generate even after you have manually added code that is not being generated from the model, you have a big opportunity to try things out easily.