The Adapter Pattern — A Simple Guide

Photo by Steve Johnson on Unsplash

You can find the source code for this post here. As always its intended to be an example, and if you find any errors please let me know so that i can correct them. The adapter pattern is a design pattern that is similar to the decorator pattern. The main difference being that the Decorator pattern must maintain the interface, while the adapter interface can change the interface. The ‘Adapter’ could simply extend an interface, or it could provide completely alternate methods than the original interface. Let’s consider an example:

Suppose you have an IFooProcessor Which has a Process method that accepts a Foo. You could create a new interface called IFooListProcessor This interface would have a Process method as well, but it would accept an IEnumerable<Foo> instead of a single foo. Now, without an adapter, you might re-create the logic inside of the foo processor just iterating through the foos. However an Adapter would accept the original interface calling it when it needs FooProcessing Behavior. Like so:

public class FooListAdapter : IFooListProcessor
{
    private IFooProcessor processor;
    public FooListAdapter(IFooProcessor processor)
    {
        this.processor = processor;
    }
    public void Process(IEnumerable<Foo> foos)
    {
        foreach (Foo foo in foos)
        {
            this.processor.Process(foo);
        }
    }
}

Now you can have many implementors of IFooProcessor and the single adapter will adapt any of them to work with a list. If you really stop and think about the possibilities at this point, you could perform all kinds of adaptations using this pattern. This might be a good place to to say, if your ‘knee jerk’ reaction to solving a particular problem is inheritance, stop and ask yourself if an adapter might solve the problem in a more flexible way. This isn’t ALWAYS the case, but its worth considering.

Now we need to figure out how we are going to present our interface to the consumer. As with any abstraction this can be the most difficult part. We could have many implementors, and several adapters. How do we allow the consumer to choose which configuration they would like to use. My personal preference is using a Builder or Factory. I will be posting articles on the builder pattern and factory pattern, but i wanted to cover some of these structural patterns first.

Whomever is going to instantiate our implementation is going to want an easy way to configure all of the options that we could provide. Using the builder pattern we could provide an interface that looks like this:

builder.StandardProcessor()
    .AdaptForLists()
    .GetProcessor();

Where you could swap out ‘StandardProcessor’ with any other implementations of the processor, and you could add methods for any other adapters you might have. One thing to note here, is that you would want to instantiate any decorators before your adapters. decorators should decorate the original interface, and therefore your ‘AdaptForLists’ function would be one of the last things called. Additionally adapters will always be mutually exclusive. Since your adapter is an entirely new interface, you cannot combine adapters like you can decorators. For example, if you have several adapters in addition to the list adapter, the consumer would have to pick one instead of being able to use all 3. You could enforce this through the structure of the builder, but i will be covering that in my post on builders.

This is only the second design pattern i’m posting about. Please respond to let me know your thoughts, or if there is a pattern you would like me to post about. Thanks for reading!