Rationale behind own layer in front of the standard API

by h22   Last Updated July 17, 2017 10:05 AM

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?

Tags : design


Related Questions




Designing DAOs for entities with common set of fields

Updated October 11, 2016 09:02 AM