Changing return value to a subclass a downward compatibility hazard?
We are writing some 'framework' code that is deployed as jar-files and used by several client applications.
I have a factory class with a static method createSomething() that returns an instance of class Something. I want to change that method to return a SometingMoreSpecial. SomethingMoreSpecial is a subclass of Something.
May this cause downward compatibility problems for the client applications? Will their binary code run with the new jar-files or will they have to recompile?
Thank you!
>May this cause downward compatibility problems for the client applications?
NO, it will not cause any downward compatibilty problems, because your new return type is a sub of old type.
but due to polymorphism basics, the client applications will execute the sub-class methods which override the super-class ones.
if you need more explanation, tell me.
>Will their binary code run with the new jar-files or will they have to recompile?
No you need not to recompile your libs.
Good Luck
Ahmad Elsafty
To reassure that you won't have any problems, the new return type should of course be a super type of all classes of which your factory can create an instance.
So if your new subclass wasn't a supertype of your classes before, your clients will have to recompile!
Message was edited by:
Peetzore
ok, I actually tried it and I do get an exception if I don't recompile the client code:
java.lang.NoSuchMethodError: Factory.createSomething()LSomething;
In the byte code of the client the method appears to be identified by name, arguments AND return type.
I could keep the old return type Something and have all clients that need the extra functionality of the subclass SomethingMoreSpecial make a cast.
Anybody knows a better solution?
Message was edited by:
Carsten.Drossel
>I could keep the old return type Something and have all >clients that need the >extra functionality of the subclass >SomethingMoreSpecial make a cast.
What if a client tries to casta Something object (not a SomethingMoreSpecial one) ?
I think, the better solution is to add a new method createSomeSthingMoreSpecial [Factory class] for example.
Hope That Helps
I think java_2006's solution is indeed cleaner than yours. You don't want to use a factory method for things it wasn't intended for. An extra method will guarantee that existing code will get access to the same old object it used to work with and an extra method will guarantee that you can get the sub objects safely where new features are required.
I've also been thinking in the direction of the Abstract factory pattern, but there you're still stuck on the common supertype.
> I've also been thinking in the direction of the
> Abstract factory pattern, but there you're still
> stuck on the common supertype.
Which is exactly the point of Abstract Factory. It all depends on whether the client code is supposed to know the actual class of the returned object.
If yes, create a separate method to create a subclass (Factory Method). If not, just keep a single superclass returning method and return the subclass from there (Abstract Factory).
