Wednesday, June 01, 2005

The ugliness has to go somewhere

"The ugliness has to go somewhere" - one of our standard design principles. Given there is some complex (or ugly) code that has to be done... do you put it in the client or in the supplier? If you put it in the supplier, then every client gets it for free. If you don't put it in the supplier, so that your class, function, etc. can remain "pretty" and simple, then every client needs to do it. Overall, putting the ugliness in the supplier makes the overall system easier to understand. For some reason not everyone gets this. But its something we pretty much live by.

I had someone ask me yesterday, who had been working on a class for a couple of weeks. "Was all of this that much easier than just the 15 lines of code that I could have hardcoded to accomplish this?" - In other words - was this worth all the effort, given it would replace 15 lines of code with a couple?

And in almost all cases, the answer to that is Yes. For one thing, it took the person a couple of weeks because they are new to OO design and to using COOL (CLIPS' OO language). So it was a good learning experience. But in addition to that
  • The functionality is now encapsulated in one place, so can be maintained and performance tuned in that one place. This is better, even if the code is more complex because it is generic and meets several needs.
  • The functionality, which is complex at times, is now encapsulated in an interface. Therefore, people that want to use the functionality only need to use the simple interface, they don't need to solve the problem or figure out how someone else solved it and copy/paste the code. This serves as a form of documentation as well, which is also a very good thing.

I've heard it said before, "A programmer is someone who will spend 2 hours coding sometihng that will save them 15 minutes." - To some extent that is true - and if that is all it was, it would be a waste of time. But factor in learning, reuse and maintainability, and it is often times the way to go.

1 comment:

Anonymous said...

This is probably ~the~ most powerful part of OO programming, and one of the hardest to train people (read manager) to understand.

Hiding the guts of intricate coding behind the interface allows you and anyone else, who maintains the code that inherits from it, to concentrate on solving the problem at hand.

Thanks to OO, gone are the days of "Search and replace" against multiple source files! Now, we simply modify the "guts" part, and a simple recompile cascades the changes to all dependants.

WOOT!