包装还是不包装开源框架？ [复制]答案

【问题标题】：to wrap or not to wrap an opensource framework? [duplicate]包装还是不包装开源框架？ [复制]
【发布时间】：2011-12-21 15:52:29
【问题描述】：

可能重复：
Should you wrap 3rd party libraries that you adopt into your project?

我正在使用 mail.jar，这是一个开源 api，用于在 java 中发送邮件。

我想知道是否应该像这样将它的调用包装到我自己的框架中：

DedicatedFramework.sendMail(subject, body, recipientList);

然后，这个专用框架将对 mail.jar 进行必要的调用。

这个想法是，如果明天我用一个弃用/更改方法的新版本替换 mail.jar，那么我会减少我的耦合。

另一方面，我添加锅炉代码只是为了“隐藏”框架。

你们对此有什么看法？

当然，它可以是邮件以外的其他框架：图片管理、jdbcTemplate、GoogleCollections ...

【问题讨论】：

【解决方案1】：

没有。

您知道明天您将不得不使用不同的邮件库吗？甚至有可能吗？我对此表示怀疑。仅仅为了“也许有一天”而包装是最糟糕的一种 YAGNI。

另一方面，如果您的 sendMail() 方法执行的操作会在您发送邮件的任何地方重复执行，那么它不是包装器，而是有用的抽象。

【讨论】：

【解决方案2】：

把它包起来。在可用的东西和如何使用它之间架起一座桥梁，这将为您节省 1) 大量样板代码和 2) 在发生细微变化但您必须在 20 个地方进行更改时大量维护该代码。

这个问题完全有可能没有被展示出来。我们的内存限制是什么？我们可以支持加载那些额外的类吗？就像任何其他问题一样，我们必须确定进行换行会面临哪些问题。

但是，如果没有任何内容显示“我们无法包装，因为 __”，那么我建议您这样做。

【讨论】：

【解决方案3】：

我会把它包起来。将代码全部集中在一个位置时，查找和更改代码会更容易。

【讨论】：

【解决方案4】：

一般来说，API 相当稳定，类/方法通常不会消失，它们会被弃用。在您的特定情况下，mail.jar 非常稳定，所以我不会费心包装它。

我的建议是不要浪费您的时间在 API 之上编写 API - 从长远来看，这将花费您更多的时间而不是节省的时间。在过去的十年中，我使用了许多库，唯一遇到过麻烦的是一个内部团队编写的库——他们重构并更改了包名和方法名。这破坏了很多代码。我从未在开源库中体验过这种情况。

【讨论】：

【解决方案5】：

包装

不要包装

【讨论】：