什么时候，为什么以及如何使用包装纸？

Question

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

所以问题就在于我为什么要使用包装器。 （在过去，我受到经验丰富的编码员的鼓励，为第三方库提供包装。）我得出以下结论;请告诉我他们是否错了，或者你有什么要补充的。

• 如果库未在应用程序中广泛使用（例如，仅由一个或两个类使用），请不要编写包装器，只需直接使用它。 （特别是如果它是一个便携式库。）
• 当你写包装时，不要认为你可以制作一个大小适合所有的包装器。写一些适合lib的优点的东西。
• ...但在某些情况下，您仍然可以充分概括包装器，以便切换库更容易一些。 （例如：大多数图形库使用图像和字体。）
• 当库提供的功能超出您的需要时，Wrappers非常有用。您可以在包装器中隐藏不需要的功能。
• 对于C libs（如果您使用的是C ++），您还可以编写一个包装器来帮助您进行自动内存管理。

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

Answer 1

我认为你已经击中头部，包装只是为了让某些东西可能被换掉是一个坏主意。经典的例子是一个数据库，他实际上曾经不得不从SQL切换到Oracle（我知道人们有，但是多久和确实有一个包装器确实有帮助？）。

根据我的经验，如果一个包装器隐藏了对第三方组件的2个以上的调用，或者api进入一个调用，这意味着调用代码的某些东西（基本上是facade pattern)或者它包含代码并为调用者添加值/类型转换（adapter pattern）。

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

Answer 2

如果你想孤立地测试，那么Wrappers就很强大了。例如，我的开发系统与我的客户activedirectory没有连接，该目录包含用户名和角色。所以我有一个UserInfoWrapper-Interface有两个实现：一个使用activedirectory，另一个使用假用户数据进行开发。

Answer 3

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

通过创建包装器来抽象第三方库需要花费一些成本。您需要决定成本是否值得。对于例如在UI工具包或库上创建包装器是非常困难的（或者至少涉及显着的开发成本）。相反，为第三方日志库创建包装器相对容易。

Wrapper还可用于在第三方库之上提供特定于域的API和简化的API。门面图案可能有所帮助（正如Paul Hadfield上面提到的那样）。