Take the 2-minute tour ×

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?

share|improve this question
Making the same API call in 5 different methods doesn't violate DRY. Keep It Simple and don't abstract until it's needed. –  kirk.burleson Sep 10 '11 at 17:18
What's a design smell? –  Aerovistae Jun 9 '12 at 17:27
add comment

migrated from stackoverflow.com Sep 8 '11 at 23:31

This question came from our site for professional and enthusiast programmers.

5 Answers

up vote 3 down vote accepted

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.

share|improve this answer
yes, even though the calls are only present in five or so methods (presently), wrapping the logic (specifically, marshalling/unmarshalling an object to/from JSON) provides for a single point of change if I later down the track decide to use a different Object-to-JSON utility API. –  wulfgar.pro Sep 10 '11 at 0:48
add comment

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.

share|improve this answer
The ability to swap out third-party code easily is a great weapon when your the party is a vendor who wants to keep your business. –  Blrfl Sep 9 '11 at 0:11
Oops... s/your the/your third/ –  Blrfl Sep 9 '11 at 0:43
add comment

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.
share|improve this answer
add comment

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




share|improve this answer
How does Gateway differ from Facade? –  Steve Evers Sep 9 '11 at 21:40
add comment

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

share|improve this answer
Functionally you would get the same result, but not all aspects of code development are about function. –  Pemdas Sep 9 '11 at 16:51
add comment

Your Answer


