> For the complete documentation index, see [llms.txt](https://jrp.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jrp.gitbook.io/notes/design-pattern/structural-adaptor-pattern.md).
# Structural - Adaptor Pattern
Imagine you are on a trip in America and want to buy a toy there. In America, people use US dollars (USD), but in India, we use rupees (INR). If you want to know how much something costs in your money (INR), you need help to change dollars into rupees.
An **adaptor** is like a magic friend who helps you. You go to your magic friend and say, “How much is this toy in rupees?” Your friend looks at the price in dollars, knows the rules (how many rupees for each dollar), and tells you the answer in rupees!
In the example:
* There is a price in dollars (the way America does it).
* The adaptor knows how to convert dollars into rupees, so you understand the cost.
* You don’t need to worry about dollars—your magic friend (adaptor) helps you talk in the language you know: rupees.
So, the **adaptor pattern** is like a bridge that helps two people who speak different “money languages” understand each other. Your friend turns “dollars” into “rupees” so you can visit and buy things easily!
### Low Level Design
adaptor pattern
### Implementation
#### Type A
```java
public interface MarketPrice {
long cost();
}
```
```java
public class MarketPriceUSD implements MarketPrice{
@Override
public long cost() {
return 20L; // returns in USD
}
}
```
#### Adaptor
```java
public interface ForexAdaptor {
long cost();
}
```
```java
public class ForexAdaptorImpl implements ForexAdaptor {
// Has-A
MarketPrice price;
ForexAdaptorImpl(MarketPrice price) {
this.price = price;
}
@Override
public long cost() {
return price.cost() * 70; // return INR
// hardcoded for simplicity.
// This should use some conversion rate mechanism.
}
}
```
#### Client - Type B , which doesn't understand USD.
It needs value in INR
```java
public class ForexClient {
public static void main(String[] args) {
ForexAdaptor adaptor = new ForexAdaptorImpl(new MarketPriceUSD());
System.out.println("Cost in INR : " + adaptor.cost());
}
}
```
#### Output
```
Cost in INR : 1400
```
Hope you understand the adaptor pattern in simplest form.
A classic example of the adapter pattern in the JDK is the use of **java.util.Arrays.asList()** method.
* The method takes an array (which doesn’t implement the `List` interface) and returns a `List` view backed by that array.
* Here, the `Arrays.asList()` method acts as an **adapter**, allowing array data to be used where a `List` is expected.
* Under the hood, it wraps the array in a private static class (`Arrays$ArrayList`) that implements the `List` interface—adapting the array interface to match the `List` interface.
**Advantages of the Adapter Pattern:**
* **Bridges Incompatible Interfaces:** Lets classes work together even if they weren’t designed to do so, by providing a “bridge” between them.
* **Promotes Reuse:** You can reuse existing code (like third-party libraries with different interfaces) without modifying the source.
* **Follows Open/Closed Principle:** You can add new adapters for more integrations without changing existing code.
* **Flexible:** Easily add adapters for new types or data sources (like supporting USD, Euro, etc.).
**Disadvantages of the Adapter Pattern:**
* **Extra Layer of Code:** Adds an additional level of indirection, which can make code more difficult to trace and debug.
* **Code Complexity:** Too many adapters in a large system can clutter the codebase and make the design harder to manage.
* **Sometimes Hides Inefficiencies:** May encourage mixing code that might not belong together, potentially masking design issues that could be solved differently.