Frustrations of Knowing How To Do The Job Right

When it comes to improving the existing code base, I am in a target-rich environment.  We have 250 Java classes that all have the name nnnCodeWrapper.  The purpose of each class is to provide an association between a code number and a description for all the different menus that make up the various screens that users can enter.

Each CodeWrapper retrieves this association from the Informix database the first time it is called, and then all subsequent references to the class retrieve that information.  That isn't terribly startling or bad.  What is bad is that all 250 classes use nearly the same method to initialize an array by calling the database; each uses nearly the same method for retrieving and manipulating the array.  The only differences are:

1. The name of the Informix stored procedure.

2. The name of the class that the array contains.

3. The details of how each column coming back from the stored procedure is parsed and dropped into the list.

Yes, those of you who have done object-oriented programming are probably scratching your heads and saying, "If these 250 classes are essentially identical, why isn't there a superclass called CodeWrapper with all 250 classes inheriting from it?  Why not just make the subclasses unique for what is really unique?  You would substantially reduce the amount of source code, probably reduce the code space (depending on how smart the Java compiler is), and prevent having to rewrite the same code when you discover a bug in one version."

And it turned out that it only took me about three hours to beat the first couple of these classes into inheriting from CodeWrapper, using abstract methods.  But then again, the state pays me badly, and as near as I can tell, paid some "experts" piles of money some years back to write this entirely wrong.  Those experts are doubtless making $100 an hour somewhere miswriting Java for some other state government, somewhere.