Design Patterns? Isn't that related to UX/UI design? No, we are talking about patterns in software design. Design patterns has everything to do with software architecture and structure. As you start with programming you will usually start with procedural code, this is the opposite of object oriented programming. Software design patterns are not tied to programming languages, you can apply these patterns to any language that supports object oriented programming. Any programming language is good for patterns. Matter of fact, patterns should always be considered in every context of any given language. Patterns are reusable solutions to solve potential issues while building software. There are a lot of different types of software design patterns that can be used to solve problems while developing. Patterns are there to help!What does this mean for you and your development process?
In this blog post we will take a closer look to the adapter software pattern. It's probably one of the simplest design pattern and you are probably using this pattern already - in real life - without even knowing it! You are probably using this or maybe your phone is currently charging with this. Let's use the micro SD adapter as example. It's a wrapper around your micro SD card so you are able to put this adapter into your computer or laptop. After plugging it in, it will be able to read your files or images. Because the interface of the micro SD card isn't matching with the SD card reader, we have to use a adapter to match the interfaces together.
The adapter pattern is basically doing the same but with your classes. You can have mismatching interfaces or a interface is too big and you want your client/application to have a small subset of the facilities on offer.
In this example we are using Facebook and Instagram as two services. You can use the Facebook class and use the method postToFacebook() to create a post on Facebook. However, for Instagram we have our Instagram class with the method postToInstagram(). Two different interfaces but we would like to treat them as one. First we are going to create our interface. An interface is simply a contract that defines what the properties of an class should have. We want to create a adapter because our two incompatible interfaces/services doesn't work together. The adapter design pattern allows incompatible classes to work together by converting the interface of one class into the interface expected by the clients. For this example I will be using PHP but you can use any other object oriented programming language.
Let's review what we have above. We have two classes with mismatching interfaces. Let's imagine that both of these classes are from external developers/packages. So we couldn't really modify these classes. However, we want to use these classes and make use of the same interface. That's the point that we apply this pattern. Let's start with our first adapter class. We create a new interface for every adapter type e.g. Facebook, Twitter and maybe more in the future.
You could see a interface as a contract. Every class that implements this interface should atleast have the methods from the implemented interface. The idea here is that the consumer of the interface says: "I want an animal to feed. I don't care if it flies, walks, or crawls. I don't care if it's big or small. I only care that it shares some features with all other animals" -- features that would comprise the definition of the interface. Let's create our first adapater class.
This is our first adapter class. As you see, we implement our SocialMediaAdapterInterface. Because we make use of this contract, we have to implement our required methods. This is exactly what we want! The next step is accepting our actual SocialMedia in the constructor. From this point we can map our authenticate and post method to the correct methods on the external class. At this point we make use of dependency injection! Let's move on to our second adapter class
This class is actually almost the same. Again, we implement our SocialMediaAdapterInterface. We map our Twitter methods so we can make use of the adapter.
Now we can make use of our class and make our socialMedia variable dynamic. Later on in our code we could still make use of the authenticate and post method because we are now sure that our adapater is implementing this interface and these methods will exists.Conclusion
A great application is constantly hooked into other libraries and APIs. I propose that we implement this design pattern, so that we do not experience any trouble when a third-party API or library changes its code base which is a common problem!