Blog Archives

Adapter Pattern

Once again it sounds more difficult than it actually is.

What is an Adapter?

An Adapter sits in between two objects that cannot be changed and cannot talk to each other. It is like the American and British power socket:

  • The socket shape and voltage are different.
  • You cannot change the situation. The source and the target are static.
  • An adapter can connect the two systems.

Adapters can also connect to several source or target objects. Let’s imagine a database is split in two. An Adapter could connect to the two separate databases and return the result as if it was just one. Using several source objects is uncommon. It does make sense, when events from two or more sources need to occur before the access to the target object can take place.


I’d say that the Adapter pattern is not more than a workaround, it is a compromise to avoid other problems. There is a difference between chewing gum and glue. Both can hold pieces together … somehow.
Imagine a British datacenter with 1000 (US->UK) power socket adapters. It would work, but don’t wonder, when someone stumbles over a adapter and disconnects something important.

(The WPF value converter is similar, not the same though. The converter eg. accepts a string and returns a double.)

Here is a short example:

namespace demo {

  public interface IPrinterDriver {
    void Print(string xText);
  } // interface

  // Client
  public class PrinterDriver : IPrinterDriver {
    private readonly IPrinterDriver _Driver;
    public PrinterDriver(IPrinterDriver xDriver) { _Driver = xDriver; }

    public void Print(string xText) { _Driver.Print(xText); }
  } // class

  // Adaptee
  public class Windows3_1_MatrixPrinterDriver {
    public void Init(string xCommandSequence) { ... }
    public void ParkPrintHead() { ... }
    public void Print(string xText) { ... }
  } // class

  // Adapter
  public class Win8_to_Win31_PrinterDriverAdapter : IPrinterDriver {
    private readonly Windows3_1_MatrixPrinterDriver _Driver = new Windows3_1_MatrixPrinterDriver();
    public void Print(string xText) {
    } //
  } // class

  class Program {

    static void Main(string[] args) {
      Win8_to_Win31_PrinterDriverAdapter lAdapter = new Win8_to_Win31_PrinterDriverAdapter();
      PrinterDriver lDriver = new PrinterDriver(lAdapter);
      lDriver.Print("Hello World!");
    } //

  } // class
} // namespace

In many examples the adapter inherits the Adaptee AND the Interface, which would then look like this:

public class Win8_to_Win31_PrinterDriverAdapter : IPrinterDriver, Windows3_1_MatrixPrinterDriver { ... }

I disagree with such approach and rather use create a private readonly field instead. It is easier to avoid naming conflicts then.