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.
2
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.
5
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.
1
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.
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.
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