Home/ Questions/Q 876503
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T11:26:34+00:00

We are using a library provided by someone else. Of late due to changes

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is a relatively common practice to wrap unstable APIs and libraries with custom wrappers.
    One common use, for example, is to translate exceptions of that library into your nomenclature of exceptions.

    More generally these wrappers are known as an Adapter, though Adapters (IMHO) are more meant for providing functionality needed by one side while hiding the exact “language” of the other side, not because the other side is unstable.

    You mentioned the use of statics though – I’m generally not a big fan of using these. IMHO it is better sometimes to have an interface represent the functionality you need, and then have subtypes of that interface, when one of these subtypes uses the third party library. The advantage of that is that can one day switch to another vendor without changing every call in your system.

    Either way, you’re generally on the correct track. IMHO anyone who thinks CTRL-H is a valid refactoring tool is asking for trouble. Are they at least using getters and setters (Where applicable) in their code?

    Also, the readability part is unclear to me. An adapter with a readable name is just as good as an original API with a readable name.

    • 0