The Value Of Reuse

time to read 2 min | 395 words

Hammet has posted a comment from his article about Castle. The comment basically talks about reuse in NVelocity, one of the MonoRail's View Engines.

NVelocity is not a full fledge programming language, and that means that you can't do some things that you can do with a full langauge (at least not easily). The end result is that you really don't want to write TheUberGrid in NVelocity, so you may end up writing a one-off, per scenario template, instead of a general control that can accept anything you throws at it and is infinitely more configurable.

Surprisingly enough, or maybe not, the one-off effort usually pays better dividends in terms of the amount of effort involved to get what you need. There is quite a bit to say about specialized solutions to those problems. I had an UberGrid myself, and in order to add a new datatype, I need to edit a dictionary of type > parsing delegate. Sure, it can handle everything from enum localization to showing descriptive text of every object in the system. But I dread the day that I'll have to display the same object in two different forms, since that is not supported, and will require major re-writing.

We're using this UberGrid quite a bit, and it's... nice. But it doesn't really gives us anything. I still code the template per page, setting all the parameters, ordering, etc. It would be just as much work to do it in place, and there wouldn't be any duplication of effort or code. More and more, I'm leaning toward simpler solutions, rather than complex ones.

On the surface, the simple solution may not have all the quantities to do interplanetary navigation (which I don't relish doing in NVelocity), but I find that more often than not, I don't need to do this kind of stuff in those scenario. Good design will keep duplication away, but it shouldn't, and mustn't be at the cost of additional complexity or abstraction.

One off solutions, to one off scenarios are not to be discouraged. When you get the second duplicate scenario, then it is time to start worrying about reusing staff. And because you already got a working implementation, it will be much easier.