ADAPTER DESIGN PATTERN

Using the adapter pattern for external libraries in Angular.

shahid ahmad bangash
ngBangash
Published in
4 min readOct 9, 2020

--

Before starting the coding phase of our project, we need to choose, which design patterns will be implemented in our project. which help the team member to use these design pattern as a template for their code.

The Design Pattern

The problem that we are trying to resolve is already solved by someone.design pattern is the mature solution of the commonly occurred problem, which resolved by experienced developers. It gives life to our project. It will help the project to sustain for the long term by adding features, with less modification. Even you can explain your thoughts to fellows without getting into detailed discussion. the open-close design principle that we need to take care of every time when we design the system.

“open for extension but close for modification”

Before diving into the adapter design pattern, I want to share my experience with the problem, that I resolved by the adapter design pattern.

I am working on an angular project. we started in an angular first version which is commonly called angular2. we integrated many external libraries directly in the project, like for toaster we use ng2-toastr, for the date we used moment.

As we know angular released a new version after every six months, so maintaining the existing project with an external library was really a headache.

We face the following problems when upgrading to the next version.

  1. Is an external library compatible with the new version?
  2. Sometimes we need to replace the existing libraries with other libraries like ng2-toastr with an angular material snackbar and moment with date-fns.
momentjs is a legacy project now

Its the official post from moment js that we are no more adding any new feature to moment js and also we are not working to make it tree shakable.

What we will do if we used the momentjs library directly in the project in all places without creating a wrapper around(a.k.a adapter pattern). imagine you use moment in most places, now need to replace it with date-fns. how many changes we need to require. it almost very dangerous if we did not write unit tests, so replacing Momentjs with date-fns may produce severe bugs in the project.

what if we want to replacing ng2-toastr with snackbar, we injected ng2-toastr directly in almost 70% of the components. we need to modify almost 70% of the project. we just violated the open-close design principle.

How we can reduce the effect of replacing the external libraries❓

Adapter pattern.

In simple words.

“Wrap an existing class with a new interface the client expect”.

The above problem can be resolve by using an adapter pattern.

after facing the above problem we just start creating a wrapper around the external and even our own npm package.

let’s create an adapter for the toaster. we can identify common methods, for that can be used in the project to show a toaster. Like for error, we show a red background color. For success, we show a green background color.

we created an adapter, will use this manager service throughout the application. now we are safe. if we want to replace this toaster with any other toaster, the only changes require here only 💥 💥. so simple, flexible, reusable, extensible like if you want to add “info” toaster, you just need to write a function and pass CSS class to panelClass and use in the application. if you want to replace, you just need to inject anther library and done.

you can do for other libraries too like for date and time management we can create wrapper like

if you check, we can easily move from moment js to date-fns by only changes in DateTimeManagerSerivce, not in the full app.

also, we can create an integration test for this service. where we don’t care about the library(moment or date-fns) used by DataTimeManagerService.

you need to create an integration test of the external library here. you don’t worry about which library will be used by DateTimeManagerService.if these tests were cleared, other all tests inside the app automatically cleared even if you replace the library.

Conclusion

The Adapter pattern is simple, flexible, testable, reusable, and extensible. we can easily change the underline vendor class without affecting the client. even the client(consumer) doesn’t know which class is used by the adapter.

Follow me on Medium or Twitter to read more about Angular, Javascript, and design pattern.

--

--

shahid ahmad bangash
ngBangash

I’m a Frontend Engineer at SMSAMI.inc, open source maintainer and contributor, blogger.