在API兼容更改的情况下，向库添加新的依赖项是否会影响二进制兼容性
本文关键字：依赖 是否 兼容性 二进制 影响 添加 API 情况下 | 更新日期: 2023-09-27 18:28:06
我的问题：
只要库的外部API是向后兼容的，那么向库添加新的依赖项是否会影响二进制兼容性？
我的情况：
我的CBOR库包含用于任意精度算术的类（在PeterO命名空间中）。（它在C#和Java中；Java版本在一个单独的存储库中，但相同的问题适用于两个版本。）
我已经将这些类移到了一个新的命名空间（在PeterO.Numbers中），并对它们进行了重命名（为了向后兼容性，保留了原始类），因为它们现在所在的命名空间只包含实用程序类。我计划将新类移到一个单独的库中，并使CBOR库将该库作为依赖项调用，因为任意精度类在CBOR之外显然很有用。（我计划最终弃用旧类。）
但我担心以这种方式创建一个单独的库是否是二进制兼容性问题，这样我不仅可以更新次要版本，还可以更新主要版本。在撰写本文时，CBOR库的版本为2.3.1。我能做到这一点并将版本更改为2.4或仅3.0吗？
只要你一开始就有一个接口，并且你的所有库的客户端都知道这个接口，你就可以了。只要你的库有一个客户端能够理解的接口，并且它实现了这个接口，那么你的代码在库中或库外的库中的位置都无关紧要。
这是一个由来已久的问题，COM（组件对象模型）在15年前就已经解决了。将您的接口与实现分离，您就是黄金。
我将回答Java版本。Java语言规范的这一部分详细描述了在保持二进制兼容性的同时可以对应用程序进行的更改。
据我所知，您的更改（尽管它们可能会影响源代码的很大一部分）是简单的重构，将一些实用程序类暴露给另一个模块，并重新引导旧类来调用这个新模块。这在"软件包的演变："一节中进行了描述
新的顶级类或接口类型可以添加到包中，而不会破坏与预先存在的二进制文件的兼容性，前提是新类型不重用以前为不相关类型提供的名称。
因此，这不会破坏二进制与使用库的现有类的兼容性。任何用于调用CBORUtil.doArithmetic()的现有类CBORClient都将继续工作，而无需重新编译，因为该方法仍然存在，只有其主体已更改为调用另一个模块来进行计算。
在下一个主要版本之前，最好避免添加新的依赖项。在此之前，在内部添加更改，并使用相同的类创建新的任意精度库，并在没有依赖项的情况下同步它们。
因此，对于版本2.4，在新名称空间中添加更改，并从旧类中调用它们，为任意精度类创建另一个类库，并将它们同步到CBOR库的下一个主要版本