什么会导致向后兼容不可能？

Question

我们有一个平台组件(用Java编写),现在应该向后兼容一段时间,例如3年.是否有可能实现新功能或修复错误必须要求平台中的接口更改？

一个具体的例子是,假设在平台中定义了某种监听器接口,客户端代码将实现监听器.稍后在监听器中需要一个新方法来引入一个新功能,但我们不能这样做,因为它会破坏接口,以便某些客户端无法编译.

创建一个使用新方法扩展原始界面的新界面是一个好主意吗？需要此新功能的客户端现在将实现新接口,并且不需要更改其他客户端代码.当然,平台中的调用现在应检查侦听器的类型,如果它是新方法的新接口,则将调用新方法,或者不执行任何操作.

这种改变可能会使代码看起来不那么简单,但我想它仍然有效.是否有必要在平台上更改接口？

Answer 1

是否有可能实现新功能或修复错误必须需要更改平台中的界面？

是的，如果此错误是向后兼容性的意外破坏，并且您在检测到此破坏之前已经发布了该产品的多个版本（X+1 ... X+N）。因此，一部分客户端依赖于旧版本 X，但另一部分客户端依赖于 X+1 ... X+N 损坏的版本。如果您修复此错误，则较新的客户端（X + 1 ... X + N）将被破坏。

创建一个新接口并使用新方法扩展原始接口是个好主意吗？

有可能，但您可能会遇到这些接口的命名和文档编译的问题。我建议您推迟此类功能并每 3 年中断一次 API，并提供如何更改旧客户端的详细说明。

当然，平台中的调用现在应该检查监听器的类型，如果是具有新方法的新接口，则将调用新方法，否则将不执行任何操作。

向后兼容性有3种：二进制（运行旧客户端）、源（旧客户端重新编译）和行为。如果需要向接口添加新方法，则只能通过检查使用的接口版本（final String VERSION = "N"）并仅针对兼容版本调用新方法来破坏源兼容性，但保持二进制兼容性。因此，如果某些旧客户端需要新功能，则应该对其进行更改并重新编译。