About Me

(Edit: I accidentally originally fat-clicked the publish button in the middle of creating this post. Sorry for the spam in your reader!)

So, you have some code that you can’t change for some reason. Maybe it’s an external library. Maybe it’s a crucial bit of code that too many things are coupled to, and changing it would be a big headache. Regardless of why, it does the work you need to do (for the most part!) but it’s not exposed in a way you like, or a way that fits 100% what you need to do. So how can you still use it? Also, how can you test that you’re using it correctly? Enter: The Adapter Pattern!

The basic idea, and then some

So, with the adapter pattern, the general goal is changing one interface to a desired interface. On top of that, this pattern will also help bring testability to your code. If you’re not familiar with TDD/BDD, or just generally unfamiliar with testing your .NET code, here’s some of the things I’ll be using in this post:

nUnit – Unit testing framework. You can also use MSTest (comes with Visual Studio).

It has lots of methods on the base class that we want to use (although their parameters weren’t exactly what we wanted at times)

So, to give an example – the class (in the external library) looks approximately like this:

1: publicabstractclass UnchangeableBaseClass

2: {

3: publicvoid PerformOperation(string generalOperationName)

4: {

5: //Magic stuff happens

6: }

7:

8: publicabstractvoid RunMe();

9: }

We have a base class we can’t modify. We have to implement RunMe() to tie it into the system. And on this base class, is a function, “PerformOperation”, that we want to take advantage of, but we don’t like passing in a string.

Our Code

So, we go to implement our class, so here’s what we end up with:

1: publicclass YourClass : UnchangeableBaseClass

2: {

3: publicoverridevoid RunMe()

4: {

5: PerformOperation("KeepingItReal");

6: }

7: }

So, what problems are here? Well, it’s untestable, for one. Second, we really don’t like passing in that string. Let’s try to write a test (and you’ll see how far we don’t get!) (Note: In good TDD fashion, you’d start with trying to write your test, which would help drive your design to testable code. But the goal of this post is to explain the pattern, which I think will be better served in this order. I’m probably wrong.)

1: [Test]

2: publicvoid WhenRunning_ItShouldPerformOperation()

3: {

4: var sut = new YourClass();

5:

6: sut.RunMe();

7:

8: //Assert....uh...what?

9: }

Wow. Didn’t get far there at all! It’s time for…THE ADAPTER PATTERN!

Patterns to the Rescue!

Let’s start with what we WANT the code to look like. And by that, I mean let’s define the interface we wish we were consuming.

Interested in more?

If you want more information on design patterns, I cannot recommend the Head First Design Patterns book enough. It’s the best down-to-earth book, to really help you learn not only the pattern, but help identify when to apply them. It’s like “Design Patterns for Dummies” – hell, if I can understand it, anyone can!