Adapter design translates one interface to another
In this post, we are going to learn the adapter design pattern and the usage of this design pattern.
Adapter Design Pattern
The adapter design pattern is a structural design pattern.
Structural design patterns are concerned with how classes and objects can be composed, to form larger structures.
Adapter Design Pattern Definition
Based on GoF The Adapter pattern is used to translate the interface of one class into another interface. This means that we can make classes work together that couldn’t otherwise because of incompatible interfaces.
In simple words when we have few classes(or functions in Javascript) and those classes are incompatible but should be used to meet the same goal, we can use this pattern. In another word you can wrap an incompatible class and create an adapter to use it the way you want.
Imagine that you have a card and you want to read that card using your laptop, the problem is that your card is not compatible with the USB port so you need a card reader to do this. Card reader is the adapter here! It let you read your card.
Another well-known example of adapter design pattern is a translator who translates words of a person to another person.
This design pattern is also known as Wrapper Design Pattern.
What are real-world examples of this design pattern?
- When new components need to be integrated and work together with existing components in the application.
- Parts of the program are rewritten with an improved interface, but the old code still expects the original interface.
- When you have a third party API that there is a chance it changes.
Feel free to add more examples of using Adapter Design Pattern in the comments section .
Design Pattern UML
Adapter Design Pattern
Client is the class that contains our application logic
Adaptee is the class that is incompatible with Target interface.
Adapter is the class that let the client use Adaptee class.
Talk is cheap!
Imagine that we were using Redis to store some objects in our application, but now we want to use MongoDB in some parts.
One way is to add MongoDB and rewrite the code in all places that we want to use MongoDB.
Another way is using an Adapter Design Pattern to be sure that we can easily use MongoDB.
We were using Redis and we have an interface called IStore
https://medium.com/media/2170fa392c5aa46d6da2dd6f20b05fec/href
We have our Redis Client implementation like this(Simplest way. Keep in mind that ioredis itself implements the set and get and all the other methods and we could use the Redis Client directly but just want to give access to these two methods):
https://medium.com/media/dc0e43627ae595a6d75755bbee3663ff/href
Here is the Client which is a user here. We want to know how many times other people looked at this person’s profile and also we want to add to this number when someone visits the profile:
https://medium.com/media/2b6065ccd1a3975fd97497af1a16cb10/href
Right now we are using the Redis Client but we want to use MongoDB. We know that MongoDB is not compatible with the current structure. So the solution is using an adapter :
We have a MongoDB client that we can execute queries on the database and we have these methods insertOne and findOne .We are going to implement the IStore interface and do the same thing using MongoDB methods to store and retrieve data.
https://medium.com/media/f7d5dace2a8ce9cc8203eabca427af6a/href
Also we return “OK” since this is how Redis response look like when the operation is successful.
The last part is using this Adapter class in the client class:
https://medium.com/media/f688472a234994716e218e258f604d7e/href
If you want to check these pieces together and test this example this is the MongoDB Connector file:
https://medium.com/media/89331480f60b9f0542836ae04eb16f32/href
I already know that this might not be the perfect example, but I think you can understand the purpose of this design pattern with this example.
Top comments (0)