Friday, January 14, 2005

Thoughts on Code Reuse II

by Asim Jalis

When I say that reuse is difficult in object-oriented systems, I am not really talking about classes which cannot be reused because they are too intertwined with the classes around them. Rather I am talking about classes which should be easy to reuse but are not. Even if I write a seemingly transplantable class such as Complex, or Vector, it does not transplant well. There is a wiki page about this called which talks about the issues with reuse of even simple seemingly reusable classes. Reuse of applications (Unix style) on the other hand is easy. All you have to do is drop the code into the path, and it's ready to reuse. The only case of OO reuse that I see is where the framework (such as the .NET framework, or J2EE) provides classes, which then are guaranteed to be on all machines. In this case it becomes easier to integrate with them. In the Unix world on the other hand I see widespread reuse. I have frequently written little command line programs myself that I reuse all the time. For example, I wrote a script pct2log which replaces numbers like 10% to their equivalent decimal value in log base 2. I have a script which downloads the stocks that hit their highs. Another which takes a list of stocks (such as the one provided by the first) and computes some standard stats on them. And so on. These programs are so much more useful and pliable than any object based application that I could have written to solve the same problem. So this makes me thing that this is not a coincidence. There is something about the Unix style of programming that makes reuse extremely likely. The Unix approach stacks the deck for reuse. What this means is that when I spend time writing monolithic applications I am essentially looking at a one-shot gamble. If the program succeeds I have made it. Otherwise I have not. But each time I decompose my applications into Unix style commands I am creating a kind of investment using which I can play again and again.