Structural - Adaptor Pattern

This pattern acts as a bridge between two incompatible 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

public interface MarketPrice {

	long cost();
}

public class MarketPriceUSD implements MarketPrice{

	@Override
	public long cost() {
		return 20L; // returns in USD
	}
}

Adaptor

public interface ForexAdaptor {
	long cost();
}

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

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.