A brief overview of the adapter design pattern.
Hi and welcome back to Weekly Dev Tips. I'm your host Steve Smith, aka Ardalis.
This is episode 71. This is the first tip I'm recording since going into quarantine lockdown due to the Coronavirus - the last few months were all recorded well ahead of their publication. I hope you're all staying safe and that you're finding these tips helpful. And perhaps you're listening to this from some time in the future, in which case hopefully everything turned out great!
This week's tip is brought to you by devBetter.com.
What is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page.
This week we're going to talk briefly about the adapter design pattern. This is one of the most common and useful design patterns, so it's a good idea for most developers to be familiar with it. It's described in the Gang of Four's Design Patterns book, linked in the show notes. You can also learn more about it in the great book Head First Design Patterns or my Pluralsight course, also both linked in the show notes.
This pattern is designed to solve the problem of incompatible interfaces. Typically this is an issue when you can't or don't want to change a client's expectations to match a service provider's interface. Or vice versa. For instance, let's say you have a large application and throughout it you've made calls to log diagnostic output using a particular named method with certain arguments. Now, you discover that you need to use a different logging solution, but unfortunately its method has a different name and its arguments are in a different order. Do you need to touch everywhere in your application to make the change?
Not necessarily. Instead, you can introduce an adapter. The adapter has the same interface as your existing approach, but translates from that interface to the new one behind the scenes. Your code keeps using the method signature it's used to, but you're able to point it at a different end result. Because they usually wrap the incompatible class, adapters are also often referred to as wrappers. With a w - not like rap artists.
It's against the rules to talk about the adapter design pattern without comparing it to electrical plug adapters, so here goes. If you've ever traveled and needed to use an adapter to convert your US plug appliance to fit another country's outlet, or vice versa, you've used an adapter. They're also common with electronics, for instance to convert a newer iPhone lightning port to a 3.5mm audio port on devices that lack a headphone jack. Adapters let you evolve the behavior of both the client and the service provider while still allowing incompatible combinations to work together. In this way, they decouple clients from service providers.
Although adapters are structurally very similar to decorators and proxies, their intent differs. You can learn more about all of these patterns and see code examples on Pluralsight, or in the books I mentioned earlier.
That's it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.