版本控制API
假设您有一个由API库支持的大型项目。该项目还附带了一个公共API，供最终用户使用。 有时您需要更改支持项目的API库。例如，您需要添加需要更改API的功能，新方法，或者需要更改传入或传自API的对象之一或这些对象之一的格式。 假设您还在公共API中使用这些对象，那么公共对象也会在您每次执行此操作时发生更改，这是不希望的，因为您的客户端可能依赖于API对象保持相同的解析代码才能正常工作。（咳嗽C ++ WSDL客户端...） 因此，一种潜在的解决方案是对API进行版本控制。但是，当我们说“版本” API时，听起来这还必须意味着对API对象进行版本控制以及为每个更改的方法签名提供重复的方法调用。因此，对于每个版本的api，我都会有一个普通的旧clr对象，这似乎也不可取。即使执行此操作，我也肯定不会从头开始构建每个对象，因为这将导致大量重复代码。相反，该API可能会扩展我们用于基础API的私有对象，但是随后遇到了同样的问题，因为如果不应该在公共API中使用附加属性，这些属性也将可用。 那么，这种情况通常适用于什么理智呢？我知道许多公共服务，例如Windows的Git都维护一个版本控制的API，但是我在构想一个支持该功能的体系结构而没有大量覆盖各种版本控制方法和输入/输出对象的重复代码时遇到了麻烦。 我知道，比如语义版本的尝试过程中把一些理智的时候应该发生的公共API休息。问题在于，如果对象之间的距离不远，似乎很多或大多数更改都需要破坏公共API，但是我发现没有重复代码的好方法。