Reusability bad?
April 30th, 2003 by HenThe latest copy of Dr Dobbs has an interesting article in the Embedded Space series. Normally I don’t read this series, but Ed Nisley’s topic this month was about space travel, an area I have the usual sci-fi fans interest in [and belief that space colonisation is our raison d’etre].
Ed makes a good point that only having 5 space shuttles is bad, as it has stopped new spacecraft being developed, and new concepts being considered. It seems that his topic [which was primarily on fault tree’s and bug-risk analysis it seems] also applies to reusable library development.
Having reusable code means that new code to do the same thing is not tried. StringUtils.capitalise(..) becoming popular would mean that no one else would try to solve that problem, possibly from a radically different direction, or using a JDK 1.9 feature.
Reusable Library development seems to be a hard topic. There are many debates around Commons Lang [and other Commons APIs] about whether they should all live in one jar, or all live in one project, or in many tiny projects. How do you decide that the single method in MathUtils in Commons Lang is worthy of Jakarta Commons Maths. How many methods do you need for it to have its own sub-package, its own package, its own jar etc.
Along with that, the above issue of stopping technology becoming stagnant gets interesting. Java itself had this problem, not enough new features being added to Java allowing C# to get the leap ahead on the language features.
April 29th, 2003 at 10:19 pm
I think that reusability is good; and I think that reusability via SPECIFICIATIONS is where the real magic is. Specifications, when they are aligned properly with most common ideas allow for a lot of room to grow for implementations; and it also ensures that code doesn’t have to change too much to fit with ‘radical’ changes. It’s sort of like Xerces vs. Piccolo. Piccolo is much much faster, but, only supports SAX parsing, and is a subset implementation. Granted, in the future, pull parsers or some other technology may make XML parsing via Sax a way of the past, but, my code needs refactoring at that point anyway. Having a single point of contact for change is nice, because, if someone does completely change the way that StringUtils.capitalize works for themselves, that single point (the StringUtils class) can be changed, and everyone that upgrades gets the massive performance improvements. Reusability doesn’t cause decay in future growth; it helps it. Developers scour code, and if StringUtils.capitalize() can be improved, someone will eventually bring it up and change it.
April 30th, 2003 at 9:54 am
Eh? What you say doesn’t make much sense. I’d think it is great that there is a StringUtils.capitalise(…) function already implemented. Why would anyone want to re-implement it? I would think it to be a major mistake to do it again, unless the current implementation was buggy, or very slow.
I’m really happy that Java doesn’t try to heap new features on top of the language all the time. I like Java to be a rather small language with a huge library. Sure, it has, for example, no enum’s, but I can live with that, since programming around it is no big deal, and the new enum proposal for 1.5 is a crime to humanity.
May 1st, 2003 at 5:46 am
Re-usability is a double edged sword. The good thing is that change to a common component ripples through to all that use it. The bad thing is that change to a common component ripples through to all that use it. What you tend to see is in the interest of stability of the platform, common components have a very low rate of change which can lead to stagnation. This is more true of strongly-typed languages I would say.