1

I have seen few projects where access to many system-specific functions was wrapped into the project-specific intermediate layer. Examples included functions for logging (wrapped around Log4J), file IO (methods like write content to the file, catch IOException), resource access, using properties and things the like. Most of the methods in this redirecting layer had very little code. The team used code review to enforce everyone to call this helper layer regardless if they see it useful or not.

The arguments for using this layer were that "we may add the standard code on every action of this type", "the API may change, our layer will stay" and that "many developers are not competent enough (in case of using layer around Hibernate)". Maybe also that some code can be reused.

The drawbacks may be that the layer library is a piece of code to maintain itself, even competent developers must learn it first when newly hired, and young developers learn some API they will not find anywhere else, rather than learning standard things and that it may restrict the possibilities available on the API it wraps around.

Is such a layer library a recommended approach or anti-pattern?

h22
  • 905
  • 1
  • 5
  • 15
  • 2
    related: [What is an Anti-Corruption layer, and how is it used?](https://softwareengineering.stackexchange.com/q/184464/31260) – gnat Jul 17 '17 at 09:56
  • Yes, one of the answers could be "if you have clear vision and specs how the API can be simplified for your specific case, of the provided API is looks over engineered". This is different from wrapping everything in a row. – h22 Jul 17 '17 at 12:56

2 Answers2

4

One of the main reasons for doing this is indeed to hide complexity or protect your system model from corruption. But there is another advantage that becomes more important over time: maintainability.

If you use important services of a third-party module, you often use them in more than one place. Say there are 5 entry points to the library, and you use them three times on average - 14 calls all in all. Now when the third-party library changes its interface, you have to change your own code in 14 places. If you had hidden away that library, you'd only have to change 5 places, and all of those changes are confined to the adaptation layer.

This means that future maintenance of this aspect of your app can be done by a specialist (e.g. a database op for a database driver, or a maths expert for a statistical analysis package) who needs no knowledge of your core workflow at all, and conversely, none of your business developers need bother with the change at all. Division of work is the one uncontested good idea that human economy thrives on, and adaptation layers enable division of work.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 1
    Most of the serious APIs are frozen. – h22 Jul 17 '17 at 11:17
  • @h22 Being frozen is not a permanent condition. – Blrfl Jul 17 '17 at 12:30
  • Some projects have aggressive API strategies: change API often and drop deprecated methods early. I agree that projects known for such behaviour may deserve the effort to write and maintain intermediate layer for them. This could be another answer. – h22 Jul 17 '17 at 12:57
1

From the referenced answer and comments that I tried to collect together, looks like it makes sense to have the wrapping layer if:

  • You have vision how the different API would allow you much better design than the original API.
  • The API team is known for the frequent but tiny aggressive tweaks (method renamed, etc) that can be fixed on the wrapper layer.
  • The usage of the API requires lots of reviewing (security sensitive, performance sensitive, very complex or simply buggy)
h22
  • 905
  • 1
  • 5
  • 15