I thought I'd be clever, look where it got me... I have data that needs to be 'massaged' before my process can use it. So I wanted to make things easy on myself and I tried to figure out a way to enable dynamic, run-time decisions about how to massage the data. Because certain datasets need to be massaged in certain ways.
So my idea was to have an interface "Massager" that contains one method "massage". Then all of my massaging classes will implement this interface. As an added benefit, since they all implement the interface, I can refer to them through an interface variable.
And then my code that tries to generically use this would use nice little mappings and Class.forName() to get an appropriate massager instance...
This compiles, but fails at runtime with a ClassCastException. I can't use the more general instance of 'Object' that getInstance() returns, because of course, Object doesn't have a massage method. I've also tried this scheme with abstract superclasses. This involves replacing my interface with an abstract class. My more specific classes then extend this class, and my variables are not interface type, but the superclass type.
I admit, I'm totally bamboozled why this won't work. Isn't that an advantage of interfaces? Anyways, has anyone implemented this type of behaviour? What am I doing wrong? [ March 12, 2003: Message edited by: Mike Curwen ]
well, this is extremely frustrating, and yet gratifying.
I changed *nothing*, but when I switched to my classes directory, I noticed a misplaced class file (I changed a few packages during development). I deleted all classes, recompiled everything, and now it all works as expected.