Coding style 是否有一种方法可以避免有时强加给我们的向后不兼容？

有时，第三方库在更改接口时会造成严重破坏。在某些语言中，它甚至发生在语言层面

有没有可能以一种可以阻止它的方式来编写我们的代码

例如，我可以想到一种方法——编写自己的包装函数。
这样，更改将局限于一个函数。但是，这又会产生很大的开销

---

你有什么想法吗？

苹果向其开发者建议，你的代码可以检查版本；然后，当版本更改时，您可以根据需要更新代码。以下是他们更深入讨论的链接：

---

基本上，它们提供了可以在头文件中使用的标记，以指示组件将要使用或已知工作的最大版本。

基本上，您包括某种版本机制（通常比低/高版本限制粒度更大），并尝试保持接口分离和“正交”。但这在很大程度上取决于界面的哪一面。在“消费者”方面，你只能做这么多

IBM System/38及其后代设法保持了兼容性，使得在第一个版本上编译的程序在30年后仍然可以运行，而无需重新编译（并且通过对机器指令集的两次修订，第二次相当激烈）。但这是一个非常好（虽然不是完美的）原始设计的不寻常的例子，再加上保持兼容性的强烈动机（大型银行在系统上花费了大量美元）

---

在个人计算机层面上，许多系统设计师并不真正关心，因为不兼容会带来更多的软件升级，而软件升级又会带来更多的硬件。

这是一个有趣的哲学问题，但除了“经验”和“运气”之外，没有任何实际的答案。通常，被宣传为防止这一问题的计划恰恰相反。（我没有投票决定是否结束，但我怀疑在我完成这篇评论时，这篇文章将会结束。）（补充：好吧，我错了，这表明预测未来有多难。）我举了一个实际想法的例子。我认为可能还有更多。当然，在针对iOS 4编写的iPhone应用程序中，在iOS 5手机上运行的可能不到50%。苹果做出了多个不向上兼容/不向下兼容的更改，中间甚至没有一个部分版本可以兼容这两种更改。因此，苹果的建议应该是有保留的。不管苹果是否遵循了他们自己的建议，版本检查仍然是向后兼容性的另一个有效想法——这是你自己在这个问题上的答案中认可的。是的，但它很少做得很好，或者有足够的粒度。诺基亚的Symbian产品基本上已不复存在，这项工作做得相当不错。