Menu
We have a platform component (written in Java) that now shall be backward compatible for a certain period, e.g. 3 years. Is there a possibility, that implementing a new feature or fixing a bug must require an interface change in the platform?
One concrete example is, let's say there is some kind of listener interface defined in the platform, and the client code will implement the listener. Later a new method seems needed in the listener to introduce a new feature, but we cannot do that because it will break the interface so that some client will not be able to compile.
Is it a good idea to create a new interface that extends the original one with the new method? The client that needs this new feature will now implements the new interface, and other client code needs not to be changed. Of course the invocations in the platform shall now check the type of the listener, if it is the new interface with the new method, then the new method will be invoked, or nothing will be done.
This kind of change may make the code look not so straightforward, but I guess it shall still work. Are there any cases that an interface change in the platform is a must?
470
In other words, you should ensure that the existing functionality of the API will remain intact while the new functionality is added. An API is backward compatible if a client (a program written to consume the API) that can work with one version of the API can work the same way with future versions of the API.
Backward compatibility (sometimes known as backwards compatibility) is a property of an operating system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system, especially in telecommunications and computing.
In a way, adding backwards compatibility to any console reflects the manufacturer's willingness to go the extra mile towards preserving video games made for older generation gaming platforms. More than just a novelty, backwards compatibility plays a crucial role in preserving older video games.
Forward compatibility or upward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself.
Is there a possibility, that implementing a new feature or fixing a bug must require an interface change in the platform?
Yes, if this bug is an accidental break of the backward compatibility and if you've released several versions (X+1 ... X+N) of the product before detecting this break. So, one part of your clients depends on older version X, but another part of clients depends on the X+1 ... X+N broken versions. And if you'll fix this bug, then newer clients (X+1 ... X+N) will be broken.
Is it a good idea to create a new interface that extends the original one with the new method?
Possible, but you'll probably got a problem with naming of these interfaces and with documentation compilation. I recommend you to delay such features and break API each 3 years with supplying of detailed explanation of how to change old clients.
Of course the invocations in the platform shall now check the type of the listener, if it is the new interface with the new method, then the new method will be invoked, or nothing will be done.
There are 3 kinds of backward compatibility: binary (running old clients), source (recompilation of old clients) and behavioral. If you need to add a new method to the interface, then you can only break source compatibility but keep the binary compatibility by checking used interface version (final String VERSION = "N") and calling new method only for compatible versions. So, if some old client need a new feature, then it should be changed and recompiled.
85
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
