Adapter pattern

In software engineering, the adapter pattern is a software design pattern (also known as wrapper, an alternative naming shared with the decorator pattern) that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.

An example is an adapter that converts the interface of a Document Object Model of an XML document into a tree structure that can be displayed.

Overview
The adapter design pattern is one of the twenty-three well-known Gang of Four design patterns that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.

The adapter design pattern solves problems like:
 * How can a class be reused that does not have an interface that a client requires?
 * How can classes that have incompatible interfaces work together?
 * How can an alternative interface be provided for a class?

Often an (already existing) class can not be reused only because its interface does not conform to the interface clients require.

The adapter design pattern describes how to solve such problems:
 * Define a separate  class that converts the (incompatible) interface of a class  into another interface  clients require.
 * Work through an  to work with (reuse) classes that do not have the required interface.

The key idea in this pattern is to work through a separate  that adapts the interface of an (already existing) class without changing it.

Clients don't know whether they work with a  class directly or through an   with a class that does not have the   interface.

See also the UML class diagram below.

Definition
An adapter allows two incompatible interfaces to work together. This is the real-world definition for an adapter. Interfaces may be incompatible, but the inner functionality should suit the need. The adapter design pattern allows otherwise incompatible classes to work together by converting the interface of one class into an interface expected by the clients.

Usage
An adapter can be used when the wrapper must respect a particular interface and must support polymorphic behavior. Alternatively, a decorator makes it possible to add or alter behavior of an interface at run-time, and a facade is used when an easier or simpler interface to an underlying object is desired.

UML class diagram


In the above UML class diagram, the  class that requires a   interface cannot reuse the   class directly because its interface doesn't conform to the   interface. Instead, the  works through an   class that implements the   interface in terms of  :


 * The  way implements the   interface by delegating to an   object at run-time.
 * The  way implements the   interface by inheriting from an   class at compile-time.

Object adapter pattern
In this adapter pattern, the adapter contains an instance of the class it wraps. In this situation, the adapter makes calls to the instance of the wrapped object.



Class adapter pattern
This adapter pattern uses multiple polymorphic interfaces implementing or inheriting both the interface that is expected and the interface that is pre-existing. It is typical for the expected interface to be created as a pure interface class, especially in languages such as Java (before JDK 1.8) that do not support multiple inheritance of classes.



Motivation from compile time solution
It is desired for to supply  with some data, let us suppose some  data. A compile time solution is:

However, suppose that the format of the string data must be varied. A compile time solution is to use inheritance:

and perhaps create the correctly "formatting" object at runtime by means of the factory pattern.

Run-time adapter solution
A solution using "adapters" proceeds as follows: 1. Define an intermediary "provider" interface, and write an implementation of that provider interface that wraps the source of the data, in this example, and outputs the data formatted as appropriate:

2. Write an adapter class that returns the specific implementation of the provider:

3. Register the with a global registry, so that the can be looked up at runtime:

4. In code, when wishing to transfer data from to, write:

or more concisely:

5. The advantage can be seen in that, if it is desired to transfer the data in a second format, then look up the different adapter/provider:

6. And if it is desired to output the data from as, say, image data in :

7. In this way, the use of adapters and providers allows multiple "views" by and into  without having to alter the class hierarchy. In general, it permits a mechanism for arbitrary data flows between objects that can be retrofitted to an existing object hierarchy.

Implementation of the adapter pattern
When implementing the adapter pattern, for clarity, one can apply the class name to the provider implementation; for example,. It should have a constructor method with an adaptee class variable as a parameter. This parameter will be passed to an instance member of. When the clientMethod is called, it will have access to the adaptee instance that allows for accessing the required data of the adaptee and performing operations on that data that generates the desired output.

Java
Output Recharging android with MicroUsb MicroUsb connected Recharge started Recharge finished Recharging iPhone with Lightning Lightning connected Recharge started Recharge finished Recharging iPhone with MicroUsb MicroUsb connected Lightning connected Recharge started Recharge finished

C#
Output: