Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

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

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

    
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

5 Answers 5

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

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
5  
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

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

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.

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

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
4  
Functionally you would get the same result, but not all aspects of code development are about function. –  Pemdas Sep 9 '11 at 16:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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