Blogging Roller

Developing a wrapper class or API can be a way to add value to an existing API and can also be a way to isolate an existing API. Wrappers can be very useful, but when applied incorrecly, wrappers can be counter-productive and downright irritating. For example: the Coat-of-paint anti-pattern.

In this anti-pattern the developer wishes to isolate an API behind a wrapper, so he develops a very thin wrapper class for each of the classes in the API. Next, he procedes to use these wrapper classes throughout his code, but because the wrappers are so thin, his code still depends on the concepts, relationships, and often the method signatures of the wrapped API. The wrapper is like a coat-of-paint on the wrapped API, it changes the appearance of the wrapped API but does not truly isolate it.

A better approach would be for the developer to divide his code up into modules or "tiers," with each module having a well defined interface. Instead of isolating the API he wishes to hide behind a thin wrapper, the developer should have isolated the API by using it in only one of his modules.

UPDATE: Another, possibly more difficult, approach would be to develop an abstraction layer over the API that is to be isolated. If you will enventually need to switch out the wrapped API for some other API, then an abstraction layer is the way to go. It is a more difficult approach because, unless the underlying APIs are simple, developing a good abstraction over them can be a challenge.