🔌 Adapter Design Pattern in Java – A Complete Guide

📚 Table of Contents

• What is the Adapter Design Pattern?
• Key Participants
• Real world Analogy
• UML Diagram

• Java Example

  • 1. Target Interface
  • 2. Adaptee Class (Existing API)
  • 3. Adapter Class
  • 4. Client Code

• Use Cases in Real World Systems

• Advantages

• Disadvantages

• When to Use and Not to Use

• Object Adapter vs Class Adapter

• Comparison with Similar Patterns

• Best Practices and Pitfalls

• Alternatives

• Summary

✅ What is the Adapter Design Pattern?

The Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to work together by converting one interface into another the client expects.

Intent: Bridge the gap between a new interface and an existing (often legacy) implementation.

This pattern acts as a wrapper around an existing class, exposing a new interface to the client.

👥 Key Participants

🧠 Real world Analogy

Think about a mobile charger adapter. Your laptop may have a USB-C port, but your phone uses Micro-USB. The adapter converts the USB-C output to Micro-USB input so your phone can charge — even though the two interfaces don’t match.

📊 UML Diagram (Text Format)

     +--------------+
     |   Client     |
     +--------------+
           |
           v
     +--------------+       +---------------+
     |   Target     |<------+   Adapter     |
     +--------------+       +---------------+
                            | - adaptee     |
                            +---------------+
                            | +request()    |
                            +---------------+
                                    |
                                    v
                            +---------------+
                            |   Adaptee     |
                            +---------------+
                            | +specificRequest() |
                            +---------------+

💻 Java Example

📘 Scenario: You have a legacy payment system (OldPaymentGateway) and want to integrate it with your new PaymentProcessor interface.

1. Target Interface

public interface PaymentProcessor {
    void pay(String amount);
}

2. Adaptee Class (Existing API)

public class OldPaymentGateway {
    public void makePayment(String amountInRupees) {
        System.out.println("Payment made using OldPaymentGateway: ₹" + amountInRupees);
    }
}

3. Adapter Class

public class PaymentAdapter implements PaymentProcessor {
    private OldPaymentGateway oldPaymentGateway;

    public PaymentAdapter(OldPaymentGateway oldPaymentGateway) {
        this.oldPaymentGateway = oldPaymentGateway;
    }

    @Override
    public void pay(String amount) {
        // Adapting method call
        oldPaymentGateway.makePayment(amount);
    }
}

4. Client Code

public class Main {
    public static void main(String[] args) {
        OldPaymentGateway oldGateway = new OldPaymentGateway();
        PaymentProcessor processor = new PaymentAdapter(oldGateway);

        processor.pay("2500");
    }
}

Output:

Payment made using OldPaymentGateway: ₹2500

🛠 Use Cases in Real World Systems

• Integrating legacy systems with modern interfaces
• Adapting third-party APIs (e.g., wrapping Stripe's API with your own payment layer)
• Making incompatible class libraries work together
• Wrapping classes with different naming conventions or method signatures
• Supporting backward compatibility

✅ Advantages

• Promotes code reusability by allowing integration of old components
• Improves interoperability between systems
• Provides flexibility in evolving interfaces
• Encourages decoupling between client and implementation

❌ Disadvantages

• Can increase complexity with too many adapters
• Might introduce runtime overhead with deep adapter chains
• Sometimes hides the true power of the Adaptee
• Tight coupling to Adaptee may remain if not designed carefully

🧭 When to Use and Not to Use

✅ Use When:

• You want to integrate an existing class but its interface doesn’t match
• You’re using third-party or legacy code
• You’re refactoring to support a new interface gradually

❌ Avoid When:

• You can directly modify the existing class
• You don’t control the Adaptee and behavior is unpredictable
• Adapter logic becomes too complex — consider Facade instead

🔁 Object Adapter vs Class Adapter

Java only supports Object Adapters as multiple inheritance is not allowed.

🔍 Comparison with Similar Patterns

⚠️ Best Practices and Pitfalls

✅ Best Practices:

• Name adapters clearly (e.g., PaymentAdapter, LegacyToNewAdapter)
• Make adapters lightweight
• Favor object composition over inheritance
• Use interfaces to abstract clients from concrete adapters

❌ Pitfalls:

• Don't create adapter chains (adapter over adapter)
• Avoid adapting too many unrelated interfaces — use Facade instead
• Don’t tightly couple your Adapter to internal logic of Adaptee

🔄 Alternatives

📌 Summary

• The Adapter Pattern bridges incompatible interfaces.
• Useful for integrating legacy or third-party APIs.
• Involves Target, Adaptee, Adapter, and Client.
• Java supports Object Adapters (via composition).
• Be cautious of complexity and avoid overusing adapters.
• Best used when refactoring or integrating external libraries.

--

📚 Explore More Design Patterns in Java

• 🔒 Mastering the Singleton Design Pattern in Java – A Complete Guide
• ⚠️ Why You Should Avoid Singleton Pattern in Modern Java Projects
• 🏭 Factory Design Pattern in Java – A Complete Guide
• 🧰 Abstract Factory Design Pattern in Java – Complete Guide with Examples
• 🧱 Builder Design Pattern in Java – A Complete Guide
• 🔁 Iterator Design Pattern in Java – Complete Guide
• 👀 Observer Design Pattern in Java – Complete Guide

More Details:

Get all articles related to system design
Hastag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/SystemDesignWithZeeshanAli