1. Overview

In this tutorial, we’ll look at the Adapter pattern and its variations, the use of this pattern in Java, and the ways to implement it.

An Adapter pattern acts as a connector between two incompatible interfaces that otherwise cannot be connected directly. The main goal for this pattern is to convert an existing interface into another one the client expects.

The structure of this pattern is similar to the Decorator. However, the Decorator is usually implemented with the extension in mind. The Adapter is usually implemented after the initial code is written to connect incompatible interfaces. There are two main ways to implement this pattern, so let’s review them.

2.1. Object Adapter

This implementation uses composition to delegate the logic to the Adapter. It’s quite a simple way to achieve interface conformity:

In this case, the Adapter contains the Adaptee and delegates the request() method to the specificRequest() method in the Adaptee.

2.2. Class Adapter

This version of the Adapter pattern requires multiple inheritance, which is technically impossible in Java if we’re not considering interfaces with default methods. The main idea is to create the Adapter by extending both the Target and the Adapter classes. However, we can implement this in Java when we have the Target as an interface, which is easier to achieve because the Target is the part we have control of:

It looks pretty similar to the Object Adapter, but now the Adapter extends the Adaptee instead of containing it compositionally. One of the benefits of this approach is that the Adapter can be used in both contexts, as the Target, and as the Adaptee. Technically, we’ve created a two-way adapter, which might be very convenient in certain cases.

2.3. Benefits and Trade-Offs

The Class Adapter approach works best with a one-to-one mapping between the Target and Adaptee methods. This way, we can use delegation without additional implementation in the Adapter. However, if the Target interface is more complex, this approach might require extra work in the Adapter. However, we can resolve this problem by delegation:

Here, we delegate only the request() method to the Adaptee. The rest of them are taken from the ConcreteTarget. We can use composition to delegate these interface methods to the implementation to avoid code duplication. At the same time, if we don’t need a two-way adapter, we can use the Object Adapter, which would make the structure much simpler:

Thus, the way to implement this pattern heavily depends on the initial state of the codebase, if we can use interfaces, and if we need to provide the ability for adapters to work in both contexts.

3. Adapter Pattern Example

Java has an excellent example of the Adapter pattern, which we can review here. Enumeration and Iterator are two related interfaces that are great examples of adapter-adaptee relationships.

3.1. Enumeration

Both of these interfaces are quite simple, but let’s start with the Enumeration:

public interface Enumeration<E> {
    
    boolean hasMoreElements();

    E nextElement();

    default Iterator<E> asIterator() {
        return new Iterator<>() {
            @Override public boolean hasNext() {
                return hasMoreElements();
            }
            @Override public E next() {
                return nextElement();
            }
        };
    }
    
}

3.2. Iterator

The description of the Iterator interface contains the following:

An iterator over a collection. Iterator takes the place of Enumeration in the Java Collections Framework. Iterators differ from enumerations in two ways:
Iterators allow the caller to remove elements from the underlying collection during the iteration with well-defined semantics.
Method names have been improved.

Technically Enumeration has the same interface, and the only difference is the method names:

public interface Iterator<E> {

    boolean hasNext();

    E next();

    default void remove() {
        throw new UnsupportedOperationException("remove");
    }

    default void forEachRemaining(Consumer<? super E> action) {
        Objects.requireNonNull(action);
        while (hasNext())
            action.accept(next());
    }
    
}

3.3. Adapter Implementations

As we can see, the interfaces are similar and have the same goal. The default asIterator() method was added in Java 9 and contains the implementation of the Adapter pattern using an anonymous class:

default Iterator<E> asIterator() {
    return new Iterator<>() {
        @Override public boolean hasNext() {
            return hasMoreElements();
        }
        @Override public E next() {
            return nextElement();
        }
    };
}

This example uses composition, but it’s not explicit in this case. We don’t pass the Enumeration instance to the Iterator because we create the Iterator in the context of Enumeration. This way, we have direct access to the Enumeration methods. It’s a very powerful technique, which allows hiding the part of the interface and using delegation to private methods. The previous examples of the Class and Object Adapter would require public API for delegation.

However, this approach to implementing the Adapter pattern using anonymous classes is possible only if we have control over both the adapter and adaptee, which isn’t possible in most cases. Let’s imagine how we could implement the same functionality before Java 9:

public class IteratorAdapter<E> implements Iterator<E> {
    
    private Enumeration<E> enumeration;
    
    public IteratorAdapter(Enumeration<E> enumeration) {
        this.enumeration = enumeration;
    }
    
    @Override
    public boolean hasNext() {
        return enumeration.hasMoreElements();
    }
    
    @Override
    public E next() {
        return enumeration.nextElement();
    }

}

This example is identical to the Object Adapter example we reviewed previously. Let’s implement the same functionality with the Class Adapter. We’ll be using StringTokenizer for this example, as it implements Enumeration interface:

public class StringTokenizerIteratorAdapter extends StringTokenizer implements Iterator<String> {

    public StringTokenizerIteratorAdapter(final String str, final String delim, final boolean returnDelims) {
        super(str, delim, returnDelims);
    }

    public StringTokenizerIteratorAdapter(final String str, final String delim) {
        super(str, delim);
    }

    public StringTokenizerIteratorAdapter(final String str) {
        super(str);
    }

    @Override
    public boolean hasNext() {
        return hasMoreTokens();
    }

    @Override
    public String next() {
        return nextToken();
    }
}

We’ve created a two-way adapter that can be used as Iterator and StringTokenizer. The Iterator methods delegate not directly to the methods in the Enumerator but to more specific methods in the StringTokenizer.

4. Conclusion

In this article, we looked at the Adapter design pattern in Java. This is one of the most important patterns for managing the codebase’s complexity and working with legacy systems. Also, it allows reusing third-party libraries without making changes to the application and always being able to change the implementations easily.

The code backing this article is available on GitHub. Once you're logged in as a Baeldung Pro Member, start learning and coding on the project.