可能重复：
Should you wrap 3rd party libraries that you adopt into your project?
我正在使用mail.jar，一个用于在java中发送邮件的opensource api。
我想知道是否应该将它的调用包装到我自己的框架中：
DedicatedFramework.sendMail(subject, body, recipientList);
我的想法是，如果明天我将mail.jar替换为弃用/更改方法的新版本，那么我会减少我的耦合。
另一方面，我添加锅炉代码只是为了“隐藏”框架。
你们对此有何看法？
当然，它可能是另一个框架而不是邮件：图片管理，jdbcTemplate，GoogleCollections ......
答案 0 :(得分：2)
否
你知道你明天必须使用不同的邮件库吗？它甚至可能吗？我对此表示怀疑。包装只是为了＆＃34;也许有一天＆＃34;是最糟糕的YAGNI。
另一方面，如果你的sendMail()方法在你发送邮件的地方做了一些其他的事情，那么它不是一个包装器，而是一个有用的抽象。
答案 1 :(得分：0)
包裹它。在可用内容和将来如何使用它之间建立桥梁将为您节省1）许多样板代码和2）当一些小的变化但是您必须在20个位置进行更改时，很多维护代码。
这个问题完全有可能没有显示出来。我们的记忆限制是什么？我们可以支持那些加载的额外类吗？我们必须确定通过执行包装会遇到什么问题，就像任何其他问题一样。
但是，如果没有任何内容表示“我们无法换行因为 _ _”，那么我建议你这样做。
答案 2 :(得分：0)
我会把它包起来。当代码全部集中在一个地方时，更容易找到和更改代码。
答案 3 :(得分：0)
通常，API相当稳定，类/方法通常不会消失，它们会被弃用。在您的特定情况下mail.jar非常稳定，所以我不打算包装它。
我的建议是不要浪费你的时间在API之上编写API - 从长远来看，它将花费你更多的时间。在过去的十年里，我使用过很多图书馆，我遇到过的唯一一个图书馆是由内部团队编写的图书馆 - 他们重构并更改了包名和方法名称。这打破了很多代码。我从未体验过开源库。
答案 4 :(得分：0)
包装
不要换行