Adapter Pattern

• A class that would be useful to your application does not implement the interface you require
• You are designing a class or a framework and you want to ensure it is usable by a wide variety of as-yet-unwritten classes and applications
• Adapters are also commonly known as Wrappers

Intent

• Convert the interface of a class into another interface clients expect
• Allow classes to work together that couldn't otherwise due to incompatible interfaces
• Future-proof client implementations by having them depend on Adapter interfaces, rather than concrete classes directly.

Applicability

• You want to use an existing class, but it's interface does not match the one you require
• You want to create a reusable class that cooperates with unrelated or unforeseen classes (so the class can depend on an adapter interface so that future clients can implement their own version of the adapter).
• You need to use several existing subclasses, but it's impractical to adapt their interface by sub classing every one.

Implementation

Client needs to call the AdaptedOperation on the Adaptee class but it can't due to incompatible interface. So an adapter interface is created, and a concrete adapter is created which implements the interface thereby containing the Operation() method which the client expects. The Operation() method on the ConcreteAdapter calls the AdapterOperation on the Adaptee. The client calls the Operation() on the ConcreteAdapter which will in-turn call the AdapterOperation() on the Adaptee.

Multiple ConcreteAdapters (at least 1) can to be created.

1. Clients depend on the Adapter interface, rather than a particular implementation.
2. At least one concrete Adapter class is created to allow the client to work with a particular class that it requires.
3. Future client needs for alternate implementations can be satisfied the created of additional concrete Adapter classes
4. Effective way to achieve open/closed principle

A single Adapter interface can work with many Adaptees

• One Adaptee and all of its subclasses (polymorphism)
• Separate Adaptees via separate concrete Adapter implementations (follows open/closed principle)

Can be difficult to override Adaptee behavior (with Object Adapter) - Since we are using composition rather than inheritance the only way to override the behavior of an Adaptee is to sublass and then write the overridden method in the subclass

• Subclasss Adaptee and add overridden behavior
• Then change concrete Adapter implementation to refer to Adaptee subclass (If we are using inheritance, then the overridden behavior needs to be implemented only in the Adapter, which is inheriting the Adaptee)

Example in ADO.NET IDataAdapter

• DbDataAdapter
  • OdbcDataAdapter
  • OldDbDataAdapter
  • SqlClientDataAdapter

Related Patterns

• Repository
  • Common use of adapter pattern
• Strategy
  • The Concrete Adapter is often passed into a class that depends on it, thus implementing the Strategy pattern.
• Façade
  • Adapter and Façade are both wrappers. The Façade pattern attempts to simplify the interface and often wraps many classes, while the Adapter typically wraps a single Adaptee, and is not generally concerned with simplifying the interface.