什么会使向后兼容变得不可能？
我们有一个平台组件（用 Java 编写），现在应该在一段时间内向后兼容，例如 3 年。 是否有可能实现新功能或修复错误必须需要更改平台中的界面？
一个具体的例子是，假设平台中定义了某种监听器接口，客户端代码将实现该监听器。后来监听器中似乎需要一个新方法来引入新功能，但我们不能这样做，因为它会破坏接口，导致某些客户端无法编译。
创建一个新接口并使用新方法扩展原始接口是个好主意吗？需要此新功能的客户端现在将实现新接口，并且其他客户端代码不需要更改。当然，平台中的调用现在应该检查监听器的类型，如果是具有新方法的新接口，则将调用新方法，否则将不执行任何操作。
这种改变可能会让代码看起来不那么简单，但我想它仍然可以工作。是否存在必须更改平台界面的情况？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，如果此错误是向后兼容性的意外破坏，并且您在检测到此破坏之前已经发布了该产品的多个版本（X+1 ... X+N）。因此，一部分客户端依赖于旧版本 X，但另一部分客户端依赖于 X+1 ... X+N 损坏的版本。如果您修复此错误，则较新的客户端（X + 1 ... X + N）将被破坏。
有可能，但是您可能会遇到这些接口的命名和文档编译的问题。我建议您推迟此类功能并每 3 年中断一次 API，并提供如何更改旧客户端的详细说明。
向后兼容性有3种：二进制（运行旧客户端）、源（旧客户端重新编译）和行为。如果需要向接口添加新方法，则只能通过检查使用的接口版本（final String VERSION = "N"）并仅针对兼容版本调用新方法来破坏源兼容性，但保持二进制兼容性。因此，如果某些旧客户端需要新功能，则应该对其进行更改并重新编译。
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.
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.
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.