Is it good practice to abstract an API being used? [closed]

Question

I have heard a lot of people suggest when designing software that it is a good practice to build an abstraction layer around calls to a third-party API libraries.

So, if I understand this correctly, say for example I am building a web-application with jQuery. I need to build an abstract layer around jQuery and have the rest of my application code use my abstraction API vs. direct calls to jQuery.

My questions:

1. Is this a valid suggestion?
2. Would this not increase code complexity?
3. Are there exceptions to this rule?
4. Would this not nullify the benefits of abstraction and re-usability?
5. Is there an extent to which having this layer makes sense beyond which the solution would seem over-engineered?

Thanks in advance!

Answer 1

jQuery is an highly usable API, designed to work very effectively at the "application code" level. It should not need abstracting & you will not benefit from doing so whatsoever.

You may find use in building some "library components" or a small amount of library code on top of it -- factoring out application-level usage of repeating UI components & patterns, specific to your app.

In general, the advice to "abstract everything" sounds mostly erroneous. Abstraction is used for things you will, or might, have to make interchangeable. Abstraction where not needed is misguided, not useful & nothing but a cost otherwise.

jQuery is already an abstraction layer, so whoever told you this doesn't know the first thing about what they're talking about.

Rather than abstraction, a more common situation -- with other libraries than jQuery -- is that they are designed at a "library implementation" or SPI level, below the level at which your application code operates.

In this situation it is normally useful to build your own library code/ classes -- such as readers, writers, builders, and other "task-oriented" classes -- to be used by your application code with an application-level API, and drive down to the library. But again, this is not abstraction.

The three most useful places to actually use abstraction are:

1. database portability -- use Hibernate, and don't rely on DB-specific generators; and
2. application server/ OS portability. Java and servlets/JSP give you both.
3. configuration. eg, via a framework like Spring.

Answer 2

If you're building a reasonably complex web-application (UI, interaction, and data heavy) jQuery alone, which is essentially just a very good DOM manipulation and AJAX library, will not provide you the tools you need to structure your client-side code in a maintainable way.

I think the abstractions you've heard people talking about are the various client side frameworks which have started appearing in the last few years such as Backbone, Knockout, Angular and Ember, most of which use (or can use) jQuery for the stuff it's good at, principally DOM manipulation.

Any one of these frameworks will provide you the tools you need to structure your code in a modular and maintainable way, without you having to reinvent the wheel. If your web application is at all complex (or likely to become complex over time) I would strongly advise you to consider one of the above as a starting point.