Take the 2-minute tour ×

A reading through the Elecias White's book "Making Embedded Systems" (from O'Reilly) got me confused because of those two terms: Facade and Adapter patterns. The explanation she gives for both aren't clear at all.

Adapter Pattern (Pag, 19): "(...Sometimes called wrapper) It converts the interface of an object into one that is easier for a client. ... . Often, adapters are written over software APIs to hide ugly interfaces ...".

Facade Pattern (Pag. 86): "... It provides a simplified interface to a piece of code...". Then it says "... Adapter pattern is a more general version of the facade pattern".

Sadly both terms seem similar to me.

From other definitions in this site (and others) most people say "Adapter pattern makes compatible two interfaces that are incompatible". What does the word 'incompatible' mean in this context?

Most sites and books give their definitions about patterns from a higher level other than an embedded system point of view (plain C, not OOP), so the examples given aren't clear indeed.

It's worth to mention that although the book is an excellent source of knowledge, for both novices and professionals, it didn't include so much code, so one should figure out this sort of definitions.

I've tried to understand them through a couple of examples I wrote for myself, would you indicate me whether my understanding is right or not?

Example 1, Facade pattern:

/* This is a fancy API that I want to 'facade' */

fancy_gui_DrawWidget(parent, id, x0, y0, x1, y1, text, txt_color, back_color, brdr_color, draw_callback(), ... and more parameters)
/* draw the widget */

/* Here I'm using the 'facade pattern' */

mygui_DrawButton(parent, id, x, y, width, height, text)

fancy_gui_DrawWidget(parent, id, x, y, x1, y1, text, BLACK, WHITE, ORANGE, button_draw_fn, ... and some more parameters needed);

Example 2, Adapter pattern:

/* Ugly interface that I want to 'adapt' (from LPC17xx NXP's CMSIS library) */

uint32_t UART_Send(
uint8_t *txbuf,
uint32_t buflen, 
/* transmits the txbuf */

/* Here I'm using the 'adapter pattern' (I think so) for a good looking interface */

int uart0_Send(buffer, len_buffer)
/* Do some stuff */
len=UART_Send(uart0_handler,buffer,len_buffer, BLOCKING);
return 0;
return 1;

Hope I explained good enough myself. Thank you in advanced!!

share|improve this question
Throw in the Proxy pattern, to confuse yourself a bit more :) –  haylem Jul 3 '12 at 14:35
add comment

2 Answers

The Facade pattern is used to abstract away complex functionality in order to make an API easier to use.

For instance, let's say you have a bit of code that updates several objects at once:



You could create a class that wraps these three update() calls into a single call:


This is one example of a facade.

You'd use the Adapter pattern when you have a particular interface that you are required to use and an object that implements the behavior you desire but does not have the required interface.

Let's say your required interface has a method with the following signature:

void Save();

You have a class already that implements the necessary behavior, but doesn't have the interface you need, perhaps something like this:

bool Update();

You don't want to change your existing class and risk breaking code that uses it, nor do you want to recreate the wheel, so you instead create a wrapper class that implements the Save method but uses an instance of your existing class:

void Save()
   bool notUsingThisReturnValue = existingClassInstance.Update();

I've written articles outlining the use of both the Facade Pattern and the Adapter Pattern

share|improve this answer
After your comments and examples, it makes more sense to say that the "facade pattern" is a synonym of "wrapper", unlike the book's definition, because in fact, as in my example #1, the user doesn't need to fill all fields in order to draw a button through fancy_gui_DrawWidget(), so he uses instead the easier one mygui_DrawButton(). mygui_DrawButton() is "wrapping" fancy_gui_DrawWidget(). I'll check your articles, but I guess I'm in the right direction =) –  Francisco Rodríguez Jul 2 '12 at 22:09
add comment

Francisco, your example for adapter is correct. I can give another one, but it is mostly object-oriented: imagine that you have an interface for datasources all have method int readValue() and you have interface with this method for polymorphic calls. And you have another one legacy old that you can't rewrite (for example, it is managed by other team or it is not available in source code) with method int readInteger(). You can't use your original interface with readValue() method for this class, so you make intermediate class, that has int readValue() method, that delegates to void readInteger().

class Adapter implements Reader {
  private LegacyReader legacyReader;
  public int readValue() {
       return legacyReader.readInteger();

Now you can use your legacy reader with together with your new classes and interface Reader.

In plain C world you can use it if your function expects to have a pointer to a function with certain signature as an argument, and implementation function has another signature. Just wrap your function with another one with correct signature.

Facade is usually used when you have a detailed API (for example, drawCircle(), drawRect(), drawLine()) but often you need to use a combinartion of this calls and you want to avoid copy-paste or don't want to provide low-level abstractions to client code. In this case you just use this code:

class DrawerFacade {
   private LowLevelDrawer drawer;
   public void drawHouse(int i, int j) {

You can use the same concept with functions (not-OOP) API in plain C if you are talking about embedded.

share|improve this answer
So I might understand the "adapter pattern" as some kind of conversion, from one signature that already existed, to a newer one, or to another more useful under certain circumstances. I'm pretty shure I cannot use "conversion" in this context, but that makes me think clearer. –  Francisco Rodríguez Jul 2 '12 at 22:13
add comment

Your Answer


