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.
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:
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:
adapter class that converts the (incompatible) interface of a class (adaptee) into another interface (target) clients require.adapter to work with (reuse) classes that do not have the required interface.The key idea in this pattern is to work through a separate adapter that adapts the interface of an (already existing) class without changing it.
Clients don't know whether they work with a target class directly or through an adapter with a class that does not have the target interface.
See also the UML class diagram below.
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.
An adapter can be used when the wrapper must respect a particular interface and must support polymorphic behavior. Alternatively, a decorator pattern makes it possible to add or alter behavior of an interface at run-time, and a facade pattern is used when an easier or simpler interface to an underlying object is desired.
| Pattern | Intent | |
|---|---|---|
| Adapter or wrapper | Converts one interface to another so that it matches what the client is expecting | |
| Dynamically adds responsibility to the interface by wrapping the original code | ||
| Support "composition over inheritance" | ||
| Provides a simplified interface |
In the above UML class diagram, the client class that requires a target interface cannot reuse the adaptee class directly because its interface doesn't conform to the target interface.Instead, the client works through an adapter class that implements the target interface in terms of adaptee:
object adapter way implements the target interface by delegating to an adaptee object at run-time (adaptee.specificOperation).class adapter way implements the target interface by inheriting from an adaptee class at compile-time (specificOperation).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.
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.
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.
A solution using "adapters" proceeds as follows:
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.
interface ILightningPhone
interface IMicroUsbPhone
class Iphone implements ILightningPhone
class Android implements IMicroUsbPhone /* exposing the target interface while wrapping source object */class LightningToMicroUsbAdapter implements IMicroUsbPhone
public class AdapterDemo
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
RECHARGE: list[str] = ["Recharge started.", "Recharge finished."]POWER_ADAPTERS: dict[str, str] = CONNECTED_MSG: str = " connected."CONNECT_FIRST_MSG: str = "Connect first."
class RechargeTemplate(metaclass = ABCMeta): @abstractmethod def recharge(self) -> NoReturn: raise NotImplementedError("You should implement this.")
class FormatIPhone(RechargeTemplate): @abstractmethod def use_lightning(self) -> NoReturn: raise NotImplementedError("You should implement this.")
class FormatAndroid(RechargeTemplate): @abstractmethod def use_micro_usb(self) -> NoReturn: raise NotImplementedError("You should implement this.")
class IPhone(FormatIPhone): __name__: str = "iPhone"
def __init__(self): self.connector: bool = False
def use_lightning(self) -> None: self.connector = True print(CONNECTED_MSG.format(POWER_ADAPTERS[self.__name__]))
def recharge(self) -> None: if self.connector: for state in RECHARGE: print(state) else: print(CONNECT_FIRST_MSG.format(POWER_ADAPTERS[self.__name__]))
class Android(FormatAndroid): __name__: str = "Android"
def __init__(self) -> None: self.connector: bool = False
def use_micro_usb(self) -> None: self.connector = True print(CONNECTED_MSG.format(POWER_ADAPTERS[self.__name__]))
def recharge(self) -> None: if self.connector: for state in RECHARGE: print(state) else: print(CONNECT_FIRST_MSG.format(POWER_ADAPTERS[self.__name__]))
class IPhoneAdapter(FormatAndroid): def __init__(self, mobile: FormatAndroid) -> None: self.mobile: FormatAndroid = mobile
def recharge(self) -> None: self.mobile.recharge
def use_micro_usb(self) -> None: print(CONNECTED_MSG.format(POWER_ADAPTERS["Android"])) self.mobile.use_lightning
class AndroidRecharger: def __init__(self) -> None: self.phone: Android = Android self.phone.use_micro_usb self.phone.recharge
class IPhoneMicroUSBRecharger: def __init__(self) -> None: self.phone: IPhone = IPhone self.phone_adapter: IPhoneAdapter = IPhoneAdapter(self.phone) self.phone_adapter.use_micro_usb self.phone_adapter.recharge
class IPhoneRecharger: def __init__(self) -> None: self.phone: IPhone = IPhone self.phone.use_lightning self.phone.recharge
print("Recharging Android with MicroUSB recharger.")AndroidRechargerprint
print("Recharging iPhone with MicroUSB using adapter pattern.")IPhoneMicroUSBRechargerprint
print("Recharging iPhone with iPhone recharger.")IPhoneRecharger
using System;
interface ILightningPhone
interface IUsbPhone
sealed class AndroidPhone : IUsbPhone
sealed class ApplePhone : ILightningPhone
sealed class LightningToUsbAdapter : IUsbPhone
public class AdapterDemoOutput:
