The Adapter Design Pattern: Bridging Incompatible Interfaces Efficiently

10 min readJun 3, 2023

Design patterns represent solutions to common problems that occur in software design. They are best practices that can be used to solve problems developers frequently encounter. Today, we’re going to delve into the Adapter Design Pattern — a structural design pattern that allows objects with incompatible interfaces to collaborate.

The article is part of my series on Software Design Patterns. For a more general introduction to design patterns, refer to this overview article, which is an excellent starting point for exploring the fascinating world of software design patterns.

As usual, the sample code shown in the article can be found on my Github repository.

A travel adapter — Photo by Aixklusiv on Pixabay

What is the Adapter Design Pattern?

The Adapter Design Pattern is a design pattern that transforms the interface of a class into another interface that clients expect. It allows classes to work together that couldn’t otherwise because of incompatible interfaces.

Think of it as a sort of “translation” between two objects. For example, you might have an old component in your system that does exactly what you need but doesn’t fit the new system’s interface. Instead of rewriting the component, you can create an adapter that connects the new system to the old component.

There are two types of adapter patterns, Class Adapter, and Object Adapter, and the main difference lies in how they implement the adaptation.

Class Adapter

The Class Adapter pattern uses inheritance to adapt one interface to another. This is done by creating an adapter class that inherits the properties and methods of the target interface and the adaptee class.

To delve deeper into the Class Adapter pattern, let’s first lay down some definitions:

The Client interface represents the interface that our client program expects to work with. It is the interface that the rest of our software is designed around and understands.
The Adaptee is the class that we’re adapting. This class has some useful behavior, but its interface is incompatible with the rest of our code.

In the Class Adapter pattern, we solve the interface mismatch problem by creating a new Adapter class that inherits both the Target interface and the Adaptee class. This Adapter class is both a Target (because it inherits the Target’s interface) and an Adaptee (because it inherits the Adaptee’s behavior).

The Client is the class that interacts with the Target class/interface. It is decoupled from the Adaptee.
The Target interface declares the request method, which is used by the Client.
The Adaptee is the class that we want to adapt. It has a specificRequest method, which is incompatible with the Target interface.
The Adapter implements the Target interface and holds a reference to the Adaptee. When the request method is called, it translates the call to the Adaptee's specificRequest method.

Here is an implementation of the pattern in Python:

class Target:
    """
    The Target is the interface that our client code understands.
    """
    def request(self) -> str:
        return "Target: The default target's behavior."

class Adaptee:
    """
    The Adaptee is the class we want to use, but its interface is
    incompatible with the existing client code.
    """

    def specific_request(self) -> str:
        """
        Defines the specific behavior of the Adaptee.
        """
        return "Specific behavior of the Adaptee."


class Adapter(Target, Adaptee):
    """
    The Adapter makes the Adaptee's interface compatible with the
    Target's interface.
    """

    def request(self) -> str:
        """
        The Adapter uses the Adaptee's interface to call its specific
        behavior.
        """
        return self.specific_request()

# Client code
adapter = Adapter()
print(adapter.request())  # --> Specific behavior of the Adaptee.

Let’s dissect the code to understand it better

Target is the interface that our client code understands, while Adaptee is the class we want to use. But Adaptee's specific_request method isn't compatible with Target's request method.
So, we create an Adapter class that inherits from both Target and Adaptee. In the Adapter's request method, we call specific_request. This way, when the client code calls request on the Adapter, it's really calling specific_request on Adaptee under the hood.
This Adapter class is effectively “translating” calls to the request method into calls to the specific_request method. As a result, the client code can use Adaptee's functionality without any changes to its own code or the Adaptee's code.

The main limitation of this approach is that we are actually using multiple inheritance. This is not possible in all languages and has its own drawbacks.

Object Adapter

In the Object Adapter pattern, the Adapter has a different approach aligning the Adaptee’s interface with the Target’s. Instead of inheriting from the Adaptee (as the Class Adapter does), the Object Adapter contains an instance of the Adaptee. This design is based on the principle of composition, which in many cases is considered more flexible than inheritance.

Composition allows the Adapter to alter the Adaptee’s behavior in more complex ways. Instead of just calling through to the Adaptee’s methods (as the Class Adapter does), the Object Adapter can call multiple methods on the Adaptee, store state, or even call methods on multiple Adaptee instances. This flexibility makes the Object Adapter more powerful but also more complex.

Again the Client is the class that interacts with a Target instance. It is unaware of the Adaptee's existence.
The Target is the interface (abstract base class) that the Client expects to interact with.
The Adaptee is the existing class that provides some useful functionality but has an incompatible interface.
The Adapter is a concrete class that implements the Target interface and contains an instance of the Adaptee. When a method is called on the Adapter (through the Target interface), it translates that call to a method on the Adaptee. Thus the Object Adapter Pattern uses composition (the “uses” relationship) rather than inheritance to adapt the Adaptee's interface. The Adapter has an instance of Adaptee and uses its functionality internally while exposing an interface (Target) that the Client can work with.

from abc import ABC, abstractmethod


class Target(ABC):
    """
    The Target defines the interface used and expected by the client.
    """

    @abstractmethod
    def request(self) -> str:
        """
        Defines the interface used by the client.
        """

class Adaptee:
    """
    The Adaptee contains some useful behavior, but its interface is
    incompatible with the existing client code.
    """

    def specific_request(self) -> str:
        """
        Defines the specific behavior of the Adaptee.
        """
        return "Specific behavior of the Adaptee."

class Adapter(Target):
    """
    The Adapter makes the Adaptee's interface compatible with the
    Target's interface.
    """

    def __init__(self, adaptee: Adaptee) -> None:
        """
        Initialize the Adapter with the adaptee class to wrap.
        """
        self.adaptee = adaptee

    def request(self) -> str:
        """
        The Adapter uses the Adaptee's interface to call its specific
        behavior.
        """
        return self.adaptee.specific_request()

# Client Code
adaptee = Adaptee()
adapter = Adapter(adaptee)
print(adapter.request())  # --> Specific behavior of the Adaptee.

Target is an abstract base class that defines the interface the client code expects.
Adaptee is a class with some useful behavior, but an incompatible interface.
Adapter is a concrete class that implements the Target interface. It contains an instance of the Adaptee, passed to it in its constructor. When its request method is called, it calls specific_request on the Adaptee.

The client code only needs to interact with the Target interface. It creates an Adapter, passing an Adaptee to the Adapter's constructor. When the client code calls the request method on the Adapter, it's really calling specific_request on the Adaptee, but it doesn't need to know about any of this.

In summary, the Object Adapter pattern uses composition to “embed” an Adaptee instance within an Adapter, allowing the Adapter to provide a modified version of the Adaptee’s interface to the client code. This pattern is highly flexible and powerful, supporting complex adaptations, stateful Adapters, and even Adapters that coordinate multiple Adaptees.

Pros and Cons of the Adapter Design Pattern

Pros

Increased compatibility: In the realm of software, one common challenge is the integration of components that don’t align perfectly with each other due to interface mismatches. This is where the Adapter pattern shines — it enables classes with incompatible interfaces to work together smoothly. The Adapter acts as a bridge, translating requests from the client class to the format understandable by the service class (Adaptee). This seamless integration improves the interoperability of your software, making it more flexible and adaptable to changing circumstances.
Code reusability: The spirit of software development encourages not reinventing the wheel. If a software module or a class has been written, tested, and debugged, it’s beneficial to reuse it as much as possible. However, sometimes existing code doesn’t fit neatly into new systems because of interface differences. The Adapter pattern addresses this by wrapping the incompatible class with an Adapter, which exposes a standardized interface that the new system can interact with. This allows for greater reusability of existing code, even when working with newer systems, thus saving development time, reducing the potential for bugs, and promoting consistency across your application.
Single Responsibility Principle: The Single Responsibility Principle (SRP), a part of the SOLID principles of object-oriented design, stipulates that a class should have one, and only one, reason to change. In the context of the Adapter pattern, the Adapter class has a clear, single responsibility: to convert the interface of the Adaptee class into an interface that the client class can work with. The Adapter encapsulates all the complex conversion logic, keeping this responsibility isolated from other parts of the system. This makes the code more maintainable and easier to understand, as each class focuses on one specific task. By using the Adapter pattern, you’re adhering to the Single Responsibility Principle, which contributes to the creation of a robust, adaptable, and easily maintainable system.

Cons

Increased complexity: While the Adapter design pattern is highly beneficial in solving interface compatibility issues, it does introduce additional layers of abstraction to your system. This means more classes to manage, more interactions to keep track of, and potentially more dependencies. Each Adapter is essentially a new piece of code that needs to be maintained and understood. If overused or used unnecessarily, it can lead to an overly complex system with excessive classes, which can be challenging to understand and maintain. It’s essential to remember that design patterns like the Adapter should be used judiciously, and only when they solve a specific problem — in this case, interface incompatibility.
Debugging difficulty: The Adapter pattern can also add a layer of complexity to debugging. When an issue arises, it might be challenging to identify whether the problem lies with the Adapter, the Adaptee, or even the interaction between the two. For instance, if the Adapter is not translating the interface correctly, or if the Adaptee itself has a bug, the symptoms might manifest when the Adapter’s methods are called, leading to confusion about the root cause of the issue. As with all software, thorough testing can mitigate this, but it’s an essential factor to keep in mind. Good logging and documentation practices are particularly valuable with the Adapter pattern, to help illuminate the inner workings of the Adapter and facilitate debugging when issues arise.

Real-World Examples in Python Standard Library

The Python Standard Library uses the Adapter pattern frequently.

File Objects: Python’s built-in file object is an excellent example of the Adapter pattern. It wraps the system’s file resources, providing a Pythonic interface. Theopen function returns a file object that provides a simple, standardized interface (write, read, etc.) for interacting with a file. The complexities of the underlying file system and IO operations are abstracted away from us. Here’s a simple example of opening a file and writing to it:

with open('file.txt', 'w') as f:
  f.write('Hello, World!')

Itertools Module: The itertools module in Python provides a set of tools for handling iterators. They effectively ‘adapt’ the output of one iterator to become the input of the next. For example, itertools.chain can combine multiple iterables into a single one:

import itertools

list1 = [1, 2, 3]
list2 = ['a', 'b', 'c']

combined = itertools.chain(list1, list2)

for i in combined:
  print(i)           #  --> 1 2 3 a b c

Object Proxy: The wrapt module's Object Proxy is another practical implementation of the adapter pattern in Python. It wraps an object, provides the same interface, but also allows customization. In this example, wrapt.ObjectProxy wraps around an instance of MyObject and provides the same interface (value). The ObjectProxy can also override methods or add new methods, effectively adapting the MyObject instance to different contexts or needs:

import wrapt

class MyObject:
  def __init__(self, value):
    self.value = value

original = MyObject('Hello')
wrapped = wrapt.ObjectProxy(original)

print(wrapped.value)  # --> Hello

Conclusion

In conclusion, the Adapter design pattern serves as a powerful tool in your software design toolbox, particularly when dealing with interoperability challenges arising from incompatible interfaces. It offers a systematic approach to harmonizing these interfaces, thus promoting a higher level of code reusability. By maintaining a strict boundary between responsibilities, the Adapter pattern also supports adherence to the single responsibility principle, a key tenet of robust, scalable software design.

However, as with any tool, it’s important to understand the potential drawbacks and appropriate use cases. The Adapter pattern can add complexity to your system by introducing additional classes and layers of abstraction, potentially making debugging more difficult. Hence, it’s crucial to balance the trade-offs, considering the specific requirements and constraints of your software project before opting for the Adapter pattern.

When considering whether to use a Class Adapter or an Object Adapter, there are some factors you should keep in mind. The Class Adapter, using inheritance, is straightforward to implement, but it lacks the flexibility of the Object Adapter. It’s a great choice when the Adaptee’s behavior doesn’t need to be adjusted, and you simply want to expose that behavior through a different interface.

On the other hand, the Object Adapter, using composition, is more flexible and powerful, and is generally the preferred option in languages that support multiple inheritance, such as Python. It allows the Adapter to modify the Adaptee’s behavior, store additional state, or even adapt multiple Adaptees at once. It’s a better choice when you need to coordinate complex operations involving the Adaptee or when the simple interface translation offered by the Class Adapter isn’t sufficient.

Remember, the choice between a Class Adapter and an Object Adapter is not a one-size-fits-all decision. It depends on the specifics of your situation, including the complexity of the adaptation you need to perform and the characteristics of your existing classes. By understanding the strengths and weaknesses of both types of Adapters, you can make a more informed decision that best fits the needs of your software project.