Should you use popular(e.g. OpenCV,boost, Eigen, Tensorflow) types on your interfaces?

Question

Suppose you are writing a software where there is a popular existing library that does not have all the algorithms/features you want but provides some "vocabulary" (equivalents of std::vector/std::string for domain) types you could use.

Should you use that library and be tied to it or write your own types you use on for interface function signatures(with option to convert to 3rd party lib quickly - so there is no noticeable performance difference).

From what I see benefits of using 3rd party lib:

• Cheaper(no development cost, only adoption/usage cost)
• Probably much better documented/less bugs
• Less spam in code void Do(MyX& x) { ThirdPartyX xtp(x); ThirdPartyAlg(xtp);...}
• No surprises(if your types behave slightly different than 3rd party types new hires with experience with 3rd party may be surprised)

From what I see problems of using 3rd party lib:

• Hard to switch away
• Might not fit your problems perfectly/might make tradeoffs you do not like

I do not care about cost of installing/maintaining third party lib since of large projects cost is negligible.

Assume that 3rd party library is well maintained, so not some guy's github repo that had last commit 5 years ago.

Answer 1

You should define a set of interfaces based on what you want your software to do, then build some adapter to fit in the libraries you want to use (aka build role interfaces).

Avoid using the libraries "as is", or defining you interfaces matching the library you are using (avoid header interfaces).

You may find interesting posts about this under the title: "Role interfaces vs Header interfaces".

Thanks to this you will:

• Maintain your code decoupled from the libraries you will choose (it will be easy to adapt your code if you change your mind down the road, and say, switch to a new library).
• Define a contract that clearly states how you use the libraries (which makes your code readable and easy to understand).
• Keep your external libraries in the infrastructure layer (in terms of Hexagonal architecture - aka ports and adapters)
• ...

Answer 2

This particular blind spot of programmers, especially object-oriented programmers, has always fascinated me. People think of reusability as something you always want to strive for in the future, and neglect that they are at this very moment talking about reusing some code from the past. In other words, all the interfaces and abstractions you are being encouraged to create now for the sake of reusability, you will be encouraged to throw out and create new ones when the opportunity actually arises for reuse in the future.

Most of the time, you should just reuse the old code. After all, those programmers went to great lengths to make it reusable. Occasionally, there will be parts of the old code's interface you don't think you need. The vast majority of the time I have thought I was in that situation, I turned out to need that part later.

Answer 3

The best way to use a third-party library in your code is to introduce an abstraction class/layer between your code and the third-party library. This has the advantage that you can make clear which functionality you use from the third-party library (you seldom use everything from a third-party library), and also that the classes and types of the third-party library do not leak into your code. That way, you are still in control with your own code.

You can also write (unit) tests against the third-party library which calls the methods you need and evaluates the responses or actions. That way, you can easily check if the functionality of the third-party library has changed during an update or upgrade.