Is this case an overuse of abstraction?

Question

We are using a library provided by someone else. Of late due to changes in that library our project has 500 errors. When migrating to the new library we found that only 15 APIs are failing and 500 errors are repetitive (multiples occurrences of those 15 errors, as same calls are used at so many times).

So, for migration I proposed creating another internal static wrapper class, that wraps those library API calls. Because if library were to change again we will have less code to change and thus code becomes easier to maintain in future. And also by wrapping calls we avoid human errors (or unintended(overloaded) API usages).

But some folks here, don't see the point in having another wrapper class, which they feel is totally unnecessary. Their sole point of argument is that as most API changes are just one liners we can always change them using CTRL+H (Find and replace). And they also say that this extra abstraction that I am suggesting, takes away the readability (as it hides the actual API call behind another method name (even though meaningful) ) for the coder/reader.

Whats the best approach here? Am I wrong with my suggestions?

Answer 1

This is actually known as the Adapter pattern, and it's specifically created with your exact problem in mind....

Adapter is specifically used to NOT add functionality, just to adapt an interface of an API to an interface expected by the caller. The interfaces are just a handy OO tool to implement the adapters function in a consistent and managable way, the pattern itself basically describes how to solve a problem.