您应该将采用的第 3 方库包装到您的项目中吗? [英] Should you wrap 3rd party libraries that you adopt into your project?
问题描述
我今天与一位同事的讨论.
A discussion I had with a colleague today.
他声称每当您使用 3rd 方库时，您都应该始终为其编写包装器.因此，您可以随时更改内容并根据您的特定用途调整内容.
He claims whenever you use a 3rd party library, you should always write for it a wrapper. So you can always change things later and accomodate things for your specific use.
我不同意总是这个词，关于 log4j 的讨论出现了，我声称 log4j 已经过经过良好测试和时间证明的 API 和实现，所有可以想到的都可以后验配置，没有什么是你应该包裹.即使您想包装，也有经过验证的包装器，例如 commons-logging 和 log5j.
I disagree with the word always, the discussion arose regarding log4j and I claimed that log4j has well tested and time proven API and implementation, and everything thinkable can be configured a posteriori and there is nothing you should wrap. Even if you wanted to wrap there are proven wrappers like commons-logging and log5j.
我们在讨论中提到的另一个例子是 Hibernate.我声称它有一个非常大的 API 需要包装.此外，它有一个分层的 API，如果你需要，它可以让你调整它的内部.我的朋友声称他仍然认为它应该被包装，但由于 API 的大小他没有这样做(这位同事在我们当前的项目中比我老得多).
Another example that we touched in our discussion is Hibernate. I claimed that it has a very big API to be wrapped. Furthermore it has a layered API which lets you tweak its inside if you so need. My friend claimed that he still believes it should be wrapped but he didn't do it because of the size of the API (this co-worker is much veteran than me in our current project).
我声明了这个，并且包装应该是在特定情况下完成:
I claimed this, and that wrapping should be done in specific cases:
- 您不确定图书馆将如何满足您的需求
- 您将只使用库的一小部分(在这种情况下，您只能公开其 API 的一部分).
- 您不确定库的 API 或实现的质量.
我还坚持认为有时您可以包装代码而不是库.例如，将你的数据库相关代码放在一个 DAO 层，而不是抢先包装所有的 hibernate.
I also maintained that sometimes you can wrap your code instead of the library. For example, puting your database related code in a DAO layer, instead of preemptively wrapping all of hibernate.
好吧，最后这不是一个真正的问题，但非常感谢您的见解、经验和意见.
Well, in the end this is not really a question, but your insights, experiences and opinions are highly appreciated.
推荐答案
- 工作量更大
- 它使您的项目膨胀
- 它可能会使您的设计复杂化
- 它没有立竿见影的好处
- 你所写的场景可能永远不会出现
- 当它发生时，您的包装器很可能需要完全重新编写，因为它与您使用的具体库过于紧密，而新的 API 与您的不匹配.
这篇关于您应该将采用的第 3 方库包装到您的项目中吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
