64: Design Patterns: Adapter.
Take Up Code - A podcast by Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes
Categorie:
The adapter structural pattern allows you to change the interface of an object. This lets you reuse code that would not normally fit into your design. This is a simple pattern that mostly describes how to forward calls from a desired interface method to another method that you’re trying to adapt. You can either use inheritance or object composition to accomplish this. Your first choice is to use inheritance. Create a class that inherits from an interface your code expects and then also inherits from the other code that you’re trying to adapt. You’ll normally inherit publicly from the interface that your code expects and privately from the class you’re adapting. Your other choice is to use object composition where your wrapper just implements the interface your code expects and forwards any necessary calls to a member variable of the class you’re adapting. This will normally be a pointer because that gives you the power to forward calls not just to some predefined class but to any other class that inherits from the class you’re adapting. Many times, this design pattern is called a wrapper. Listen to the full episode or you can also read the full transcript below. Transcript The basic description says that this pattern lets classes work together that would not otherwise be able to. This design pattern has so many similarities to everyday examples that I’m not sure where to begin. I’ll give you several examples and hope that at least one will be something that you can relate to. The first example is overseas travel plugs or power adapters. These devices are designed to allow you to plug your electrical devices into the adapter with one set of prong arrangement and then plug into the wall outlets in a different country. Some travel plugs provide multiple adapters for various countries. Why are there so many standards for plugging things into electricity? Another example should be familiar to anybody who works with tools. Specifically ratchet sets come in sizes like 3/8 or 1/2 inch. I’m not talking about the size of the bolt that you’re trying to tighten. This is the size of the ratchet tool itself. If you want to use a socket designed to fit a 3/8 inch ratchet but you only have a 1/2 inch ratchet available, then you need a special adapter that accepts the 3/8 inch socket and then snaps into the 1/2 inch ratchet. And for another example, I’m going old school and talking about record players. Many years ago, you could buy songs on vinyl records and there were two popular formats. The smaller records usually had a single song on each side and played at a faster 45 RPMs. The larger LP records played at a slower 33 and a third RPMs. I always wondered who came up with these speeds. Anyway, the big problem was the center holes in the records were different sizes. A lot different. Not only did your record player need to change the speed that it turned, but you also needed to put an adapter in the larger center hole so the record would fit. I hope you’re getting the idea that these design patterns are really just a documented and agreed on way to describe concepts that software developers have been using for a long time. Without design patterns, developers would describe their designs with different terminology and then would spend time explaining what they meant. With design patterns, once you learn them, you’ll be able to explain where in the code you decided to use an adapter and other developers will instantly know exactly what you mean. And the opposite scenario is something you should avoid. You don’t want another developer to casually mention a design pattern when you don’t know the meaning. That one oversight could cause you to become lost because the other developer will naturally assume you know all about design patterns. Now that you know how the adapter pattern relates to the real world, I’ll explain some options you have right afte