Is wrapping third-party API calls a design smell?

Question

Five methods within my API call the same third-party method. In trying to abide by DRY, does it make sense to wrap this call in a private method?

Answer 1

Actually, I think wrapping or isolating third-party api's in a "shim" layer is good design. There are a number of advantage in doing this.

For instance, what happens if you change operating systems assuming you are not developing in managed environment like .NET (Which basically provides the shim layer for you)? If you put a shim layer over of all the system calls like message queues, mutexs, etc, this process is much less painful. I used the operating system example, because I have done this, but it applies to any type of "swap-able" code module/library. As another example, suppose you use a graphics library and at some point decide to change your vendor. The shim layer essentially allows the main application to run in a number of different environments possibly without any other changes besides what the shim layer is actually doing. This is massively advantageous when you are developing cross platform applications. Plus, everything that needs to change is on one convenient spot.

Answer 2

I would recommend you leave your code as-is.

However, say, if you're calling 20 differing methods in third-party code on 1000 lines of your code, perhaps creating a thin layer between you and your third-party code may save you (or someone else) some pain the future, in the event that the third-party code changes and you have to update all your calls.

Answer 3

The reason why you should always wrap the api is:

1. The api you're using was designed for 50 different uses, while you're choosing just one of them into use. So your function prototypes will look considerably different because the scope of the projects is different.
2. Because you can choose smaller scope, your wrapped api necessarily is considerably simpler and you get huge abstraction benefits by wrapping it
3. Obviously just manually copy-pasting the prototypes is not going to work. You actually need to make it simpler.

Answer 4

I think you don't need to do this. Anyway, you get the same result with one extra and unnecessary call.

Answer 5

Your roughly describing the Gateway pattern. No smell at all.

...Interesting software rarely lives in isolation. Even the purest object-oriented system often has to deal with things that aren't objects, such as relational data-base tables, CICS transactions, and XML data structures.

When accessing external resources like this, you'll usually get APIs for them. However, these APIs are naturally going to be somewhat complicated because they take the nature of the resource into account. Anyone who needs to under-stand a resource needs to understand its API - whether JDBC and SQL for rela-tional databases or W3C or JDOM for XML. Not only does this make the software harder to understand, it also makes it much harder to change should you shift some data from a relational database to an XML message at some point in the future.

The answer is so common that it's hardly worth stating. Wrap all the special API code into a class whose interface looks like a regular object. Other objects access the resource through this Gateway, which translates the simple method calls into the appropriate specialized API.