When is it good to expose a third party library as part of your API? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this questionI have my thoughts about this matter but it seems that a lot of libraries and products let third party libs bleed into the API. Logging is a perfect example of this. Nearly everything exposes the need for you to configu开发者_如何学Cre that logging API rather than using a provider interface that you can implement and give to the lib.
Is aiming to wrap and hide all libs asking too much ? Is it worth the trouble ?
Not only is it not worth the trouble to wrap and hide everything about the libraries, it's often counterproductive.
For example, we have a library that implements a specific HTTP protocol named OAI-PMH. This library is implemented on top of Apache HttpClient 4.0, which has a rich set of configuration parameters. Rather than make up our own configuration parameters that wrap the HttpClient ones, we just expose the Apache library's configuration interface with our own factories and constructors.
If we had tried to wrap all of the Apache parameters, it would have taken months. If we had decided on behalf of our library's users which parameters were important, and only wrapped those, we would have limited what they could do with our library.
I think a lot of it depends on what you are doing. Given the example you are talking about, I think it would be an incredible waste of time and would give the end consumers a less robust package if you completely hide the Third Party API.
For example if you are using Log4Net and hide all configuration aspects, you limit the flexibility to only the items that you integrate/expose. Now, on the flip side, there are times and places where that IS what you want to do.
So I guess the long and short of it is ONLY if there is a TRUE business need to do so. At least that is my $0.02.
加载中,请稍侯......
精彩评论