Adapter Design Pattern Implementation in Typescript
Tags: adapterpattern, wrapper, typescript, node
Published: 2023-09-12 11:58:10

---
title: Adapter Design Pattern Implementation in Typescript
published: true
date: 2021-05-16 21:48:58 UTC
tags: adapterpattern,wrapper,typescript,nodejs
canonical_url: https://levelup.gitconnected.com/adapter-design-pattern-implementation-in-typescript-a33f481b9aff
---

#### 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](https://cdn-images-1.medium.com/max/1024/1*bOFlW-vowviqn4vWncflqg.png)
_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

![](https://cdn-images-1.medium.com/max/1024/1*dvydbVU1LpRyIoeV980yaA.png)
_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**

<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/2170fa392c5aa46d6da2dd6f20b05fec/href">https://medium.com/media/2170fa392c5aa46d6da2dd6f20b05fec/href</a></iframe>

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):

<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/dc0e43627ae595a6d75755bbee3663ff/href">https://medium.com/media/dc0e43627ae595a6d75755bbee3663ff/href</a></iframe>

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:

<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/2b6065ccd1a3975fd97497af1a16cb10/href">https://medium.com/media/2b6065ccd1a3975fd97497af1a16cb10/href</a></iframe>

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.

<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/f7d5dace2a8ce9cc8203eabca427af6a/href">https://medium.com/media/f7d5dace2a8ce9cc8203eabca427af6a/href</a></iframe>

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:

<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/f688472a234994716e218e258f604d7e/href">https://medium.com/media/f688472a234994716e218e258f604d7e/href</a></iframe>

If you want to check these pieces together and test this example this is the MongoDB Connector file:

<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/89331480f60b9f0542836ae04eb16f32/href">https://medium.com/media/89331480f60b9f0542836ae04eb16f32/href</a></iframe>

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.

- [Adapter](https://refactoring.guru/design-patterns/adapter)
- [Adapter](https://dofactory.com/javascript/design-patterns/adapter)
- [Structural Design Patterns - Javatpoint](https://www.javatpoint.com/structural-design-patterns)

* * *