Insert Pith Here

Wednesday April 19, 2006

I'm learning to hate constructors

Of course, that's partially to do with the way "things are done" here. We've got a base class (we'll call A) that takes the form of Constructor(int id) where the constructor then loads values from the database after doing a lookup on id, among other things.

I've been working on a set of classes that need to work on a second database (something the original set of data objects didn't need to do), so I created an abstract class (we'll call B) which subclasses A and does some common work (common to this second set). And I've got subclass C of B.

Now, B is abstract, so it doesn't need constructors, but C has to be compatible with A (for use in a Factory) so it does have to have C(int id). But to avoid compilation errors in C(int id) { super(id); } I do have to specify B(id) { super(id) }.

So, my abstract class does have to have a Constructor. Or I can copy-paste the work A(id) does into C(id).

Have I mentioned that there is no way to enforce this Constructor(int id) contract, except by discovering that the Factory cannot instantiate your C? I could fix the Factory such that it doesn't build an object by calling a constructor, add a FactoryInterface with an initialize(id) method, and have the Factory use that instead. Now c.initialize() can override a.initialize() with no need for b.intialize(); and I only have to get this approved by the rest of the development staff. And roll this change into the 20+ classes that inherit from A.