
Design Patterns - Adapter Pattern
Originally published on my old blog at cumps.be on July 16, 2008.
We’ve seen quite a few patterns so far, and I’m glad so many people like them. They turned out to be the most popular posts I’ve ever written when it comes to development. Thanks! :)
A little overview for the late joiners:
- Long Absence - Design Patterns
- Design Patterns - Strategy Pattern
- Design Patterns - Observer Pattern
- Design Patterns - Observer/Event Pattern
- Design Patterns - Decorator Pattern
- Design Patterns - Factory Method Pattern
- Design Patterns - Abstract Factory Pattern
- Design Patterns - Singleton Pattern
- Design Patterns - Generic Singleton Pattern
- Design Patterns - Command Pattern
Today we’ll have a look at the Adapter Pattern.
As usual, the definition: “Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.”
To continue on our little game, we received a third-party library from another team, containing some buildings to include in our game. The developers of this library didn’t work with IBuilding, however; they call it a Structure, which makes all of our code that interacts with IBuilding unusable.
If we look at the definition, we can see the Adapter Pattern is the perfect solution for this, since we need to convert the interface of the third-party Structure into the IBuilding we expect, so that they can work together as if their interface was compatible.
Let’s have a look at what their interface looks like first.

There are some differences in the logic used in their implementation. We both have a Description, but the way we manage Power consumption is totally different.
Time to adapt their interface to the one we expect. We’ll do this by creating a new class, a so-called adapter, which implements the IBuilding interface, since we expect that one, and which uses composition to encapsulate a Structure.

As you can see, our Adapter is actually behaving as an IBuilding to the rest of our code, adapting the calls to our interface into calls to the third-party interface. And that’s it really! The easiest way I remember this pattern is by thinking of electrical adapters, changing the socket from US to UK, or transforming the voltages.
Time to have a look at the full diagram, with the official names written on it again:

Let’s also write some test code to see the Adapter Pattern in action.

We can reuse all of our existing code with the new Structures, since it’s behaving like an IBuilding right now.
I’ve uploaded the solution again to have a look at.
Some additional information on the Adapter Pattern:
You May Also Like

Design Patterns - Command Pattern
The Command Pattern: UI buttons that run commands without knowing about game units, with undo for the last action.

Design Patterns - Generic Singleton Pattern
A generic Singleton base class that creates its instance through the private constructor with reflection, worked out with readers' help.

Design Patterns - Singleton Pattern
The Singleton Pattern: a single GraphicsCard instance, why the simple version isn't thread-safe, and a lazy, thread-safe version with a nested class.



