何时、为什么以及如何使用包装器？

Question

我说的是第三方库的包装器。直到最近，我一直在尝试提供一个足够通用的包装器，以便在需要时轻松切换库。然而事实证明这几乎是不可能的，因为即使在处理基本概念方面，库也可能有很大差异。

所以我想到了为什么要使用包装器。 （过去，有经验的程序员鼓励我为 3rd-party 库编写包装器。）我得出以下结论；请告诉我他们是否错了，或者您有什么要补充的。

• 如果该库没有在应用程序中广泛使用（例如，仅由一两个类使用），则根本不要编写包装器，直接使用即可。 （特别是如果它是一个可移植的库。）
• 当您编写包装器时，不要认为您可以制作一种万能的包装器。根据 lib 的优势写一些合适的东西。
• ... 但是在某些情况下，您仍然可以充分概括包装器，这样切换库会更容易一些。 （例如：大多数图形库都使用图像和字体。）
• 当库提供的功能超出您的需要时，包装器很有用。您可以在包装器中隐藏不需要的功能。
• 对于 C 库（如果您使用 C++），您还可以编写一个包装器来帮助您进行自动内存管理。

您认为使用包装器的（不利）优势是什么，应该如何正确使用它们？

Answer 1

我认为你已经一针见血了，包装只是为了让某些东西可能被换掉是一个坏主意。典型的例子是一个数据库，实际上谁曾经不得不从 SQL 切换到 Oracle（我知道人们有，但是有一个包装器真的有帮助吗？）。

根据我的经验，包装器仅在将 2 次以上对第 3 方组件或 api 的调用隐藏到对调用代码（基本上是 facade pattern) 或包装代码并添加调用者的值/类型转换（adapter pattern）。

因此，包装器必须在此时此地为消费者提供利益，而不是可能永远不需要的潜在未来利益（对系统编码人员）。

Answer 2

如果您想单独测试，包装器非常强大。例如，我的开发系统与保存用户名和角色的客户活动目录没有任何联系。所以我有一个带有两种实现的 UserInfoWrapper-Interface：一种使用 activedirectory，另一种使用用于开发的假用户数据。

Answer 3

“计算机科学中的所有问题都可以通过另一个间接层次来解决”，Butler Lampson

通过创建包装器来抽象第三方库是有代价的。你需要决定这笔费用是否值得。例如在 UI 工具包或库上创建包装器非常困难（或至少涉及大量开发成本）。相反，为第三方日志库创建包装器相对容易。

Wrapper 还可用于在第三方库之上提供特定于域的简化 API。立面模式可能会有所帮助（正如 Paul Hadfield 上面提到的）。