Design pattern name for an API wrapper class [closed]

Question

I am writing a class that wraps (the parts of) an external API I am using. Let's take the GitHub API as an example.

My imaginary GitHub class now has a fetchUser() and fetchRepository() method. When GitHub decides to host their API at github-api.com I only have to change it once. Nice. But what's the name of this - very common - approach?

Could it be a facade as it's a simpler interface to a more complicated one? An adapter as it links two incompatible APIs, or should I simply call it a wrapper class?

Answer 1

Adapter pattern will have the same method name. X.DoSomething() will do different thing when it applies to different object.

Façade pattern accesses different functions in separate different classes. Example of façade class should be when you want to create a validator class.

My guess is that it may be Observer pattern, since when the object changes, another dependent object changes automatically. You are aware that MVC is an Observer pattern, aren't you?

Otherwise, it can also be Mediator pattern. So when your object in internal system wants to talk to GitHub API object, it will have to go to your class to access.

Thanks,

Answer 2

There are two common names:

Entreprise Integration Pattern

or

Enterprise Service Bus

Here are some of the examples of EIP/ESB patterns

Answer 3

You are making use of delegation. I.e. you are delegating GitHub::fetchUser() to the GitHub API. So I would call it a "Delegator".

Answer 4

Some alternative suggestions because sometimes things need to 'sound right'

It could be considered a ClientProxy. Depends how things will be packaged. Will this become a stand-alone DLL? If so, it's possibly a client proxy.

Perhaps it is only a convenience class of a larger application (ie. leaves the door open to more advanced usage)? If so, it could be a "Helper" (though I dislike the term) -- a "Utility" is better. Better still would be a "StreamlinedClient" --"Easy" or "Simple" feel too unprofessional but when combined with "Interface" they can sound reasonable: "SimplifiedInterface"

Now, if this wrapper is intended to hide the advanced implementation in such a way that your application will only use your wrapper when interfacing with the external API... it's simply a Service or a ServiceWrapper.

Facade is overused (especially in Java): and your simplified description fits; however, I tend to think of this only when encapsulating without adding much in the way of logic (sort of a workflow that is not really related to the problem being solved).