When, why and how to use wrappers?

I'm talking about wrappers for third-party libraries. Until recently I was trying to provide a general enough wrapper so I could easily switch libraries if needed. This however proved to be nearly impossible since libraries can vary greatly even in terms of how basic concepts are handled.

So the question came to me why one should use wrappers at all. (In the past I have been encouraged by experienced coders to write wrappers for 3rd-party libs.) I came to the following conclusions; please tell me if they are wrong or if you have anything to add.

• If the library isn't widely used in the application (e.g. used by only one or two classes), don't write a wrapper at all, just use it directly. (Especially if it's a portable lib.)
• When you do write wrappers don't think you can make one-size-fit-all wrapper. Write something appropriate for t开发者_开发问答he strengths of the lib.
• ... But in some cases you can still generalize the wrapper enough so that it'll be somewhat easier to switch libraries. (E.g.: most graphics libraries use images and fonts.)
• Wrappers are useful for when the library offers more functionality than you need. You can hide the unneeded functionality in the wrapper.
• In the case of C libs (if you're using C++), you can also write a wrapper to help you with automatic memory management.

What do you think are the (dis)advantages of using wrappers, and how should they be used properly?

I think you've hit the nail on the head, wrappers just to allow something to potentially be swapped out is a bad idea. The classic example is a database and who has actually ever had to switch from SQL to Oracle (I know people have, but how often and did having a wrapper really help?).

In my experience a wrapper only helps if it is hiding 2+ calls to the 3rd party component or api's into a single call that means something to the calling code (basically a facade pattern) or if it is wrapping the code and adding value / type conversion for the caller (an adapter pattern).

So the wrapper must provide a benefit here and now to the consumer, not a potential future benefit (to the system coder) that may never be needed.

Wrappers are powerfull if you want to test in isolation. For example my development system has no connection to my customers activedirectory that holds usernames and roles. so i have a UserInfoWrapper-Interface with two implementations: one that uses activedirectory and one with fake userdata used for development.

"All problems in computer science can be solved by another level of indirection" by Butler Lampson

There is a cost involved in abstracting third party libraries by creating a wrapper. You need to decide whether the cost is worth it or not. For e.g. it is extremely difficult (or at least involves significant development cost) to create wrapper on UI toolkits or libraries. On the contrary it is relatively easy to create wrappers for third party logging libraries.

Wrapper can also be used to provide domain specific and a simplified API on top of third party libary. Facade pattern could be of help (as Paul Hadfield has mentioned above).