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?

closed as primarily opinion-based by durron597, user40980, gnat, user22815, Dan Pichelman Aug 5 '15 at 18:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I'd just call it abstraction. – Ben Aaronson Oct 5 '14 at 13:10
  • 3
    Why not name the class GithubClient? – Hey Oct 5 '14 at 17:20

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.


  • 1
    'Observer' has a different meaning in the domain but mediator sounds like a good fit. Thanks! – Cimm Oct 5 '14 at 20:14

There are two common names:

Entreprise Integration Pattern


Enterprise Service Bus

Here are some of the examples of EIP/ESB patterns


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


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).

Not the answer you're looking for? Browse other questions tagged or ask your own question.