API库解耦方法？

Question

想象一组代表某些 API 的库。通过使用控制反转机制，具体的实现将被注入到消费项目中。

这是一个情况。我有一些 API 库依赖于其他 API 库来实现某些功能 - 因此 API 库本身在某些时候是耦合的。这种耦合可能会在以后成为一个问题，因为改变一个 API 会导致依赖的 API 的改变，相应的实现也需要改变，所以在最坏的情况下，我们最终会得到相当多的项目需要改变。进行修改以反映仅其中一个形式的更改。

现在我想到了两种可能的解决方案：

• 创建一个统一相关 API 库的整体 API 项目。

• 通过使每个库为依赖于其他 API 的所有功能提供接口，进一步解耦 API，从而消除直接依赖关系。这可能会导致两个库中出现类似的代码，但可以自由地通过 IoC 机制选择实现，并且还允许 API 彼此独立地改进（当 API 发生更改时，更改只会影响其实现库，而不影响其他 API 或其实现）。

第二种方法的问题是重复代码，结果可能是需要引用太多的 api 库（例如，在 .NET 应用程序中，每个 API 将是一个单独的 DLL。在某些情况下，例如 Silverlight应用程序，这可能是应用程序大小的问题 - 下载时间和客户端性能总体）。

针对目前的情况有没有更好的解决办法。什么时候最好将一些 API 库合并到一个更大的库中，什么时候最好？我知道这是我问的一个非常普遍的问题，但让我们暂时忽略截止日期、估计、客户要求和技术，我希望能够在实现最大可扩展性和最短维护时间的基础上确定正确的方法。那么，选择这两种方法或您可能建议我的另一种方法的充分理由是什么？

编辑：

我觉得我必须澄清一下这个问题。我想要的是 API 之间的解耦，而不是 API 与其实现的解耦。因此，例如，如果我有用于验证访问权限的安全 API，以及使用（引用）安全 API 的用户帐户 API，则更改安全 API 将需要更改用户帐户 API 以及两者的实现。以这种方式耦合的 API 越多，需要应用的更改就越多。这是我想避免的。

Answer 1

需要在几个大型图书馆和无数个小型图书馆之间进行选择。

• 如果您有一个巨大的库，其中的代码往往会紧密耦合，因为没有力量提供压力以松散耦合的方式设计各种元素。风险在于，发展该库变得越来越困难，因为必须协调太多的相互依赖关系。以 .NET 基类库为例。
• 如果您有无数的小库，您可能会面临dll hell 的风险。是的，我们多年前就被承诺一切都结束了，但事实并非如此。只要尝试在应用程序代码库中使用大量细粒度的开源库，您就会明白我的意思。

尽管如此，单一职责原则也适用于包级别，因此我建议使用小型的、集中的库，而不是大型的通用库。这也使得选择最佳库变得更加容易。

小库总是可以组合/编译成更大的库（在.NET中使用程序集链接器/合并/重新打包实用程序），而拆分大库要困难得多。

无论你做什么，最重要的是要记住向后兼容性。您引入的重大更改越少，这些库就越容易管理。