refactoring - 您是否应该将采用的第 3 方库包装到您的项目中？

Question

我今天和一位同事进行的讨论。

他声称每当您使用第三方库时，您都应该为其编写一个包装器。因此，您可以随时更改内容并根据您的特定用途进行调整。

我不同意总是这个词，关于 log4j 的讨论发生了，我声称 log4j 已经经过充分测试和时间验证的 API 和实现，并且所有可以想到的东西都可以事后配置，并且没有什么是你可以做的。应该包裹。即使您想包装，也有经过验证的包装器，例如 commons-logging 和 log5j。

我们在讨论中提到的另一个例子是 Hibernate。我声称它有一个非常大的 API 需要封装。此外，它还有一个分层的 API，可以让您根据需要调整其内部。我的 friend 声称他仍然认为应该包装它，但由于 API 的大小，他没有这样做(这位同事在我们当前的项目中比我经验丰富)。

我领取了this ，并且应该在特定情况下进行包装:

• 您不确定该库如何满足您的需求
• 您将仅使用库的一小部分(在这种情况下，您可能仅公开其 API 的一部分)。
• 您不确定该库的 API 或实现的质量。

我还认为有时您可以包装代码而不是库。例如，将数据库相关代码放在 DAO 层中，而不是抢先包装所有 hibernate。

好吧，最后这并不是一个真正的问题，但我们非常感谢您的见解、经验和意见。

Answer 1

这是 YAGNI 的完美示例:

• 工作量更大
• 它会让你的项目膨胀
• 这可能会使您的设计变得复杂
• 它没有立竿见影的好处
• 你所写的场景可能永远不会出现
• 当发生这种情况时，您的包装器很可能需要完全重写，因为它与您正在使用的具体库联系得太紧密，而新的 API 根本与您的 API 不匹配。