15

Inspired by this question Using third-party libraries - always use a wrapper? I wanted to know what people actually consider as third-party libraries.

Example from PHP:
If I'm building an application using Zend framework, should I treat Zend framework libraries as third party code?

Example from C#:
If I'm building a desktop application, should I treat all .Net classes as third party code?

Example from Java:
Should I treat all libraries in the JDK as third party libraries?

Some people say that if a library is stable and won't change often then one doesn't need to wrap it. However I fail to see how one would test a class that depends on a third party code without wrapping it.

Improve this question
2
  • 8
    Can the down-voter please explain why?
    – Songo
    Nov 6, 2012 at 14:55
  • I've heard about third party software, but not third party code. Most third parties don't give you their source code.
    – Tulains Córdova
    Nov 6, 2012 at 16:47

5 Answers 5

Reset to default
18

Your examples are all third-party code, but you should not write wrappers for them. They are large, mature projects with stable and well-planned APIs.

The need for wrappers is to provide a layer of abstraction between your code and the library. You only need this abstraction when you discover that a library doesn't provide good APIs for the specific thing you're doing. Then you might create the wrapper to simplify your own code, and hide the fact that the API calls are awkward.

Your code will be testable if you use dependency injection. In your unit tests you can swap out the library dependency with a mock object, allowing you to isolate your code under test.

Improve this answer
5
  • +1 for explaining when a wrapper or facade, if you will, may be necessary.
    – Joshua Drake
    Nov 6, 2012 at 22:17
  • Thanks for the answer, but concerning the last paragraph about unit testing could you take a look at this question where I'm trying to unit test a class that has direct dependency on a library framework?
    – Songo
    Nov 7, 2012 at 9:32
  • @Songo: Your test strategy should be to create a Zend_Mail mock that you pass to your Logger object under test. Doesn't PHP support duck typing? If so, shouldn't it be trivial to create a mock object...? I don't really know PHP, but you could look at examples from PHP mocking libraries to see how it's typically done. In languages that don't support duck typing, then I think you would need to change Zend_Mail to an interface, and then create a thin wrapper that implements the interface and inherits from Zend_Mail or just delegates all its calls.
    – sourcenouveau
    Nov 7, 2012 at 13:54
  • @emddudley well yes, but I was looking for a more general solution to the problem in other languages that doesn't support duck typing. Actually your solution to wrap Zend_Mail was my first thought, but as you can see in my original post before editing it I did use an interface and wrapper that implements it. However, the wrapper sole purpose to exist is so that I can mock its interface. Is that common in languages that doesn't support duck typing? Building infinite no of wrappers I mean?
    – Songo
    Nov 7, 2012 at 14:58
  • @Songo: I think it's very language- and library-specific, and you have to make do with whatever your platform supports. Sometimes you may be stuck with writing wrappers. Dependency injection and object mocking are fairly recent developments (2004?), so not all languages and libraries support them very well. The "general solution" you are looking for is just a mindset: how can you architect your code for loose coupling and effective unit testing?
    – sourcenouveau
    Nov 7, 2012 at 15:52
6

The goal of wrapping up a library is to break your own code's dependency on that library in order to enable:

  • Unit testing - You must be able to test your code. If a library does not allow you to mock the classes or force responses that you need for your test, then you'll need to wrap that library. This is an obvious problem, and probably not the case you are wondering about.
  • Changing implementations - As the code author you need to understand changes that are likely coming your way, and how much those changes will cost to prepare for compared to how likely they are. Can you switch from .NET to JVM? That's difficult and unlikely; however, you are very likely to change UI technologies in the future, or XML engines.

Isolating third party libraries and frameworks is just a subset of isolating change.

Improve this answer
1
  • Very good point about unit testing. I'm not saying always wrap in order to be able to unit test you application, but it is a good strategy for decoupling dependencies when needed.
    – Sergio Acosta
    Nov 6, 2012 at 16:14
2

I would not treat members of the standard library as 3rd party code -- they are standard after all and can reasonably presumed to be available and functional on the platform you are using.

As for something like Zend, I think that one would not wrap it -- you would probably need to rewrite the program if you took on a different framework. To be honest, I would not wrap much that wasn't a serious external configuration dependency or if I wasn't really planning on making that piece swappable.

Improve this answer
2

I would consider libraries provided by a specific programming language as just part of the language.

Than, I would consider third party, all the libraries provided by any other entity as an extension or a separate tool from the programming language itself.

Taking your example, I would consider Zend a third party. I would also construct my application in a way that my core business logic would not depend on Zend.

Wikipedia defines third party component as:

In computer programming, a third-party software component is a reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform.

Improve this answer
1

In the strictest sense, every example you gave is third party code. However, not all third party code should be wrapped. All third party libraries should be wrapped. Frameworks, by definition, cannot be wrapped because they become part and parcel of your code. That is why you would wrap your logging library, but not the .NET framework or the Zend framework. You cannot really separate your code from .NET--they are intertwined. Of course, good frameworks will have interfaces to program against, allowing you to bypass the problem to some degree.

See also: https://stackoverflow.com/questions/148747/what-is-the-difference-between-a-framework-and-a-library

Improve this answer

Your Answer

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

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