背景：
我将开发依赖于快速变化的 API 和快速变化的数据模型的工具，我将对其零控制。
数据模型和 API 更改很常见，这里的问题是我的代码必须继续与当前和所有过去的版本一起使用（即 100% 反向兼容），因为所有这些都将继续在内部使用。
当它遇到丢失/未知的功能等时，它还必须优雅地降级。
这些工具将使用 C# 和 WinForms 编写，用于测试自定义硬件。
<Edit>
我的目标是只需要创建类来添加功能，当数据模型发生变化时，创建一组新的数据模型类，这些类将由基于 API 版本的工厂创建。
我面临的挑战是，未来的功能可能取决于特定的数据模型，这些模型可能会混合和匹配（直到达到最终组合）。你会如何优雅地处理这件事？
<Edit2>
当然，一旦产品交付，我想重用该工具并为新产品添加代码。在我开始之前，每个产品周期都意味着重写（从头开始）所有工具，我打算在未来防止这种情况:)
</Edit>
问题：
为了保持与 API/数据模型的多个版本的兼容性，您会建议或已成功使用哪些设计技术和模式？
我应该注意哪些陷阱？
几乎所有的SOLID模式都适用于此，尤其是单一职责原则(SRP) 和开放/封闭原则(OCP)。
OCP 特别声明该类型应该对扩展开放，但对修改关闭- 这听起来很适合您的情况，因为这将是确保向后兼容性的一种方式。
SRP 在这里也很有帮助，因为它意味着如果一个类只做一件事，而那件事变得过时，它不会拖累很多其他问题。它只能任其自生自灭。
在更实际的层面上，我建议您遵循两个原则：
TDD（或只是一个全面的单元测试套件）将帮助保护您免受重大更改的影响。
一个可能有用的想法是 Eric Evans 在他的《领域驱动设计》一书中讨论的“反腐败层” ——该模式的主要动机是将您的系统与另一个系统的变化（和特质）隔离开来。
您提到该代码用于测试自定义硬件。你的代码（即测试程序）也会改变吗？您的代码是今天测试一个圆，明天测试一个三角形还是每天都在发展的同一个基本圆？
如果事物围绕一个恒定点移动，那么我将从那里开始，并为每个版本的 API 和数据模型编写包装器，根据其他答案中建议的技术，它们将链接到中心。
但是，如果没有恒定点并且一切都在移动，那么我将放弃该项目！做不到！
您的 API / 您的数据模型是否为您提供元数据？如果是这样，最好使用它来使您的代码尽可能独立于 API 更改。例如，如果您有机会通过使用数据模型模式来生成您的数据模型访问例程，那么您应该这样做。当然，这仅对某些类型的操作有意义。
编写你自己的包装器来连接你的代码和你无法控制的东西。然后，您可以针对包装器公开的 API 编写代码，而只需要担心包装器本身的互操作。
您最好的选择是让您公开的 API 需要一个版本号才能随请求一起提供。这样您就可以选择正确的对象来创建。最坏的情况是，每次更改都会中断，您最终会得到几十个课程。最好的情况是您的设计可以处理它，并且您只会时不时地使用单独的类。继承可能会成为你的朋友。最重要的是，如果您需要与快速变化的 API 保持 100% 的向后兼容性，那么您基本上就完蛋了。你要么最终得到一个巨大的不可维护的类，要么得到几个正确响应版本控制的类。
1）大量的单元测试。
每当您编写一段代码时，为将来的版本必须通过才能签入的代码发布大量单元测试。
确保测试基于功能需求，即不是函数是如何编写的，而是它必须做什么才能不破坏其他代码。
这将帮助人们检查破坏其他代码的更改。
2) 要求对所有 API 和数据模型进行良好的正式规范。这确保了它们的设计会更加仔细，并且不会在没有思想或理由的情况下随意进行更改。