Design pattern for wrapping a SDK

Question

Our company has purchased a SDK that can be used for Android apps. The SDK is written in java and its very big.

I have to create a wrapper for this SDK so our partners doesn't need to directly use the SDK, but call our wapper functions instead.

I am wondering what is the best design pattern for doing a job like this? I am have been looking at the proxy design pattern, but not sure if this is the correct one.

Many thanks for any suggestions,

Answer 1

The one that comes to mind is the Facade pattern.

From the Wikipedia description:

A facade is an object that provides a simplified interface to a larger body of code, such as a class library.

The facade pattern is one of the original design patterns that was described in the GoF book. There the description reads:

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Seems to fit your use case perfectly.

Answer 2

This sounds like the classic case for the facade pattern. You want to design an API for your partners that captures your high-level use cases. The implementation would delegate to this purchased SDK, but without allowing its implementation details to propagate up to your partner's code.

http://en.wikipedia.org/wiki/Facade_pattern

The proxy pattern looks less relevant to this problem. Proxy tends to be a one-for-one mapping to the wrapped API just for infrastructure requirements. The classic example is remote method invocation.

http://en.wikipedia.org/wiki/Proxy_pattern

Answer 3

The Facade pattern sounds like the most appropriate one.

However, choosing the best design pattern is not a guarantee of success. Whether you will succeed really depends on the nature of the SDK that you are attempting to "wrap", and what you are really trying to achieve by wrapping it.

For example, in a past project I made the mistake of using facade-like wrappers to abstract over two different triple-store APIs. I wanted to have the freedom to switch triple-store implementations. It was a bad idea. I essentially ended up mirroring a large subset of the API functionality in the facade. It was a major implementation effort, and the end result was no simpler. In hindsight, it was simply not worth it.

In summary:

• If you can make your facade API small and simple, this is a good idea. (The ideal facade is one that simply hides a whole bunch of complexity or configurability that you don't want the clients to use.)

• If your facade is large and complicated, and/or entails complicated "mapping" to the actual APIs you are wrapping, you are liable to have a lot of coding to do, and you may end up with something that is objectively worse than what you started with.