我说的是第三方库的包装器。直到最近，我一直在尝试提供一个足够通用的包装器，以便我可以在需要时轻松切换库。然而，这被证明几乎是不可能的，因为即使在处理基本概念的方式方面，图书馆也可能有很大差异。
所以我想到了为什么应该使用包装器的问题。 (过去，有经验的编码人员鼓励我为第 3 方库编写包装器。)我得出以下结论；如果他们错了或者您有什么要补充的，请告诉我。
- 如果库没有在应用程序中广泛使用(例如，只被一两个类使用)，则根本不要编写包装器，直接使用即可。 (特别是如果它是一个可移植的库。)
- 当您编写包装器时，不要认为您可以制作一刀切的包装器。写一些适合图书馆长处的东西。
- ...但在某些情况下，您仍然可以充分概括包装器，以便更容易切换库。 (例如:大多数图形库都使用图像和字体。)
- 当库提供的功能超出您的需要时，包装器很有用。您可以在包装器中隐藏不需要的功能。
- 对于 C 库(如果您使用的是 C++)，您还可以编写一个包装器来帮助您进行自动内存管理。
您认为使用包装器的(缺点)优点是什么，应该如何正确使用它们？
最佳答案
我认为您说到了要点，包装器只是为了让某些东西有可能被换掉是个坏主意。典型的例子是一个数据库，谁实际上曾经不得不从 SQL 切换到 Oracle(我知道人们有过，但是有多少次并且有一个包装器真的有帮助？)。
根据我的经验，包装器只有在将对第 3 方组件或 api 的 2 次以上调用隐藏到对调用代码有意义的单个调用中(基本上是 facade pattern)，或者如果它正在包装代码并添加调用者的值/类型转换(adapter pattern)。
因此包装器必须在此时此地为消费者提供好处，而不是可能永远不需要的潜在未来好处(对系统编码人员)。
关于language-agnostic - 何时、为何以及如何使用包装器？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5384657/