对 API 进行编程和对接口进行编程答案

【问题标题】：Programming an API and programming to an interface对 API 进行编程和对接口进行编程
【发布时间】：2011-06-16 03:33:14
【问题描述】：

通常建议“编程到接口，而不是实现”。它有助于促进关注点分离，并有助于单元测试。不过，我正在考虑 API 编程。

假设我编写了一个 API，并且该 API 使用了很多“接口编程”。还可以说，该 API 非常流行并被许多外部客户使用。如果 API 中的某个接口必须更改，则需要重新编译使用该 API 的应用程序。

我的问题是，如何避免此类问题（或减少此类更改的影响），还是无法避免？我不是 API 程序员，想了解这里的最佳实践。在我看来，改变一个已经存在很长时间并被广泛使用的界面是一个坏主意。

【问题讨论】：

我强烈推荐阅读这本书：amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/…这正是你所问的。
@Ivan - 完全同意；有一个很棒的2nd edition。
哦，对不起。我知道第二版，只是没有注意到我首先指出。谢谢！

【解决方案1】：

发布的界面永远不会改变。如果您必须增加功能，只需添加一个新界面即可。

引用MSDN：

当你创建一个接口时，你是创建一个永远不可能的定义接口定义后改变已被释放。这个界面不变性是一个重要的原则组件设计，因为它保护现有系统已编写为使用该接口。

当一个接口明显需要时的增强，一个新的界面应该被创建。这个界面可能是通过附加一个“2”来命名原始接口名称，以显示其与现有的关系界面。

【讨论】：

此解决方案有其缺点。一段时间后，您会得到 ISomeInterface、ISomeInterface2、ISomeInterface3 等。Office COM 类或 ESRI ArcMap 接口就是很好的例子。有时阅读和理解起来很尴尬......
@Ivan：当然，命名准则本身现在似乎已经过时了 - 如果您确实必须支持向后兼容性，尽管这些原则仍然适用。
我同意。只是想强调一下，有时为了方便而引入破坏性更改比盲目遵循指导方针要好。也就是说，这些指南当然仍然有用:)

【解决方案2】：

我认为这里可以区分 API 到服务和 API 到库。

就服务而言，这些 API 不应被破坏。向它们添加接口不会影响现有消费者。

仅当消费者想要使用更新版本的库时，更改库 API 才需要重新编译。无论如何，这很可能伴随着重新编译，并且简单地添加到接口不需要更改现有代码（如果适用，您可以使用属性标记已弃用的方法）。

如果您确实需要对 API 进行重大更改，那么是的，消费者必须更改他们的代码以使其可构建。

虽然不能掉以轻心，但有许多非常受欢迎的库，其 API 随着时间的推移发生了显着变化（我想到了 Fluent NHibernate），至少从我的角度来看，更新我的项目的痛苦是最小的，特别是考虑到这些更新带来的改进。

我认为对于图书馆来说，在采用新版本时可能需要进行一些调整。同样，如果 API 不发生变化，则预期工作代码不应被新版本破坏。

【讨论】：