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?

  • Making the same API call in 5 different methods doesn't violate DRY. Keep It Simple and don't abstract until it's needed. Sep 10, 2011 at 17:18
  • What's a design smell? Jun 9, 2012 at 17:27
  • @Aerovistae it's like a code smell, but in design rather than code.
    – user40980
    Mar 26, 2015 at 13:39

4 Answers 4


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.

  • 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.
    – wulfgarpro
    Sep 10, 2011 at 0:48
  • @Pemdas I agree that such wrapping is sometimes useful, but the danger is the creation of unnecessary levels of abstraction that don't actually get used for that purpose in the long run. If that is the case, all it adds is additional code and cognitive jump-points for the maintenance programmer. Unfortunately, often you will only know in hindsight if it was worth the effort :) Mar 25, 2015 at 8:03

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.

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.

  • 6
    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, 2011 at 0:11
  • Oops... s/your the/your third/
    – Blrfl
    Sep 9, 2011 at 0:43

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.

  • 2
    How does Gateway differ from Facade? Sep 9, 2011 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.