Adapter

The three participants

Every Adapter setup has the same three roles. Name them and the pattern becomes easy to spot anywhere:

• Target — the interface your client code expects. Here: Logger with log(message). This is the round socket.
• Adaptee — the existing class with the useful behaviour but the wrong interface. Here: XmlLoggerLib with writeXml(xmlString). This is the square plug. You can't (or won't) change it.
• Adapter — the small class in the middle. It implements the Target so the client can use it, and it holds the Adaptee inside so it can forward the real work — translating arguments, formats, or method names on the way through.

// TARGET — what the app expects (round socket)
interface Logger {
  log(message: string): void;
}

// ADAPTEE — third-party, can't change it (square plug)
class XmlLoggerLib {
  writeXml(xmlString: string): void { /* writes XML somewhere */ }
}

// ADAPTER — implements Target, wraps Adaptee
class XmlLoggerAdapter implements Logger {
  constructor(private lib: XmlLoggerLib) {}   // composition

  log(message: string): void {
    this.lib.writeXml(`<log>${message}</log>`);  // translate!
  }
}

The key line is inside log(): the adapter takes the call your app makes, reshapes the data into what the library wants, and forwards it. All the 'mismatch knowledge' lives in this one small class. And crucially, the client code never changes — every logger.log(...) in your app keeps working exactly as written. You just hand it an XmlLoggerAdapter instead of some other Logger.

Object adapter vs class adapter

There are two ways to build the adapter, and the difference is how it reaches the adaptee:

• Object adapter (composition) — the adapter holds a reference to the adaptee and forwards calls to it. This is the version above, and the one you should use. It works in every language, it can adapt the adaptee and all its subclasses, and it keeps the two classes loosely coupled.
• Class adapter (inheritance) — the adapter inherits from the adaptee (and the target at once). It needs multiple inheritance, so it only really works in languages like C++, and it welds the adapter to one concrete class. It saves a field, but that's about it.

Don't confuse it with its neighbours

• Adapter changes an interface's shape so existing code fits — it adds no new behaviour.
• Facade ([[facade]]) doesn't translate one interface into another; it invents a new, simpler front door over a whole subsystem.
• Decorator keeps the same interface and adds behaviour on top; Adapter changes the interface and adds nothing.

Reach for an Adapter when you can't change one of the sides

Adapter earns its keep whenever useful code exists but its interface doesn't match what your code expects — and rewriting either side is off the table:

• Integrating third-party or legacy code — a library, SDK, or ancient in-house module does exactly what you need, but its method names and data formats don't match yours. Wrap it once; use it everywhere.
• Making old code fit a new interface — you've designed a clean new interface and want existing classes to satisfy it without risky rewrites. One adapter per old class bridges the gap.
• Adapters at system boundaries — payment providers, logging backends, storage services. Define one Target interface for your app, then write a thin adapter per vendor. Swapping vendors becomes swapping adapters, and your core code never hears about it.