是否有一种方法可以避免有时强加给我们的向后不兼容？
有时，第三方库在更改其界面时会造成严重破坏。在某些语言中，甚至发生在语言层面。
是否有可能以一种可以阻止这种情况的方式编写我们的代码？
例如，我可以想到一种方法 - 编写自己的包装函数。
这样，更改将局限于一个函数。但话又说回来，它会产生很大的开销。
你有什么想法吗？
Sometimes, 3rd party libraries cause havoc when they change their interface. In some languages, it even happens on the language level.
Is it possible to write our code in a way that will prevent it?
For instance, I can think of one way - writing your own wrapper functions.
In that way, the changes will be localized to one function. But then again, it creates a large overhead.
Do you have any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
基本上，您包括某种版本机制（通常具有比低/高版本限制更大的粒度），并且尝试保持接口分离和“正交”。但很大程度上取决于您所在界面的哪一侧。在“消费者”方面你只能做这么多。
IBM System/38 及其后代设法保持兼容性，以便在第一个版本上编译的程序在 30 年后仍然可以运行，而无需重新编译（并且通过机器指令集的两次修订，第二次修订相当剧烈）。但这是一个不寻常的案例，它的原始设计非常好（尽管并不完美），并且结合了相当强大的动机（大型银行在系统上花费了大量美元）来保持兼容性。
在个人计算机层面，许多系统设计人员并不真正关心，因为不兼容性会销售更多的软件升级，进而销售更多的硬件。
Basically, you include some sort of version mechanism (generally with more granularity than just low/high version limits), and you try to keep interfaces separate and "orthogonal". But a lot depends on which side of the interface you're on. On the "consumer" side you can only do so much.
IBM System/38 and it's descendents managed to maintain compatibility such that programs compiled on the first release could still be run, without recompiling, 30 years later (and through two revisions of the machine instruction set, the second quite drastic). But that is an unusual case of pretty good (though not perfect) original design, combined with fairly strong motivation (large banks that spend a lot of $$ on the systems) to maintain compatibility.
At the personal computer level many system designers don't really care, since incompatibility sells more software upgrades, which in turn sells more hardware.
Apple 向其开发人员建议您的代码可以检查版本；然后您可以在版本更改时根据需要更新代码。以下是他们更深入讨论的链接：
Mac OS X 开发人员发行说明< /a>
基本上，它们提供了可在头文件中使用的标记，以指示组件要使用或已知可以工作的最大版本。
Apple suggests to its developers the idea that your code can check for versions; then you can update your code as needed when a version changes. Here's a link to their more thorough discussion:
Mac OS X Developer Release Note
Basically, they provide markers that can be used in header files to indicate the max version in which a component is meant to be used or is known to work.