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!
Adapter Design PatternThis week's tip is brought to you by devBetter.com.
Sponsor - devBetter Group Career Coaching for DevelopersWhat 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.
Adapter Design PatternThis 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.
Show Resources and Links Adapter Design Pattern in C# on Pluralsight Domain-Driven Design Fundamentals on Pluralsight Design Patterns on Amazon Head First Design Patterns on Amazon devBetter Ardalis BlogThat'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.
Blogging with guest Andrew Lock
.Net Foundation with guest Claire Novotny
Code Comments with Guest Claudio Lassala
Using the New GitHub CLI with guest John Papa
Defense in Depth with guest Matt Eland
Setting Up New Projects with guest Heather Downing
Respawn with guest Jimmy Bogard
Abstractions with guest Chris Klug
Blazor with guest Carl Franklin
A/B Testing with Azure with guest Lars Klint
Richard Campbell on Teams
Password Managers with guest Troy Hunt
Requirements and Change with Guest Juval Löwy
Mise en Place with guest Ryan Lanciaux
How Developers Fail
Versioning with guest Jon Skeet
Boundaries with guest James Hickey
Dependency Inversion Principle
One Step Build Test Run
Create your
podcast in
minutes
It is Free
Insight Story: Tech Trends Unpacked
Zero-Shot
Fast Forward by Tomorrow Unlocked: Tech past, tech future
The Unbelivable Truth - Series 1 - 26 including specials and pilot
Lex Fridman Podcast