Shulou(Shulou.com)06/03 Report--

What this article shares to you is about the embodiment of the adapter in JavaScript. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

The adapter design pattern is very useful in JavaScript and can be seen in dealing with cross-browser compatibility issues and integrating multiple third-party SDK calls.

In fact, in daily development, we often inadvertently write code that conforms to a certain design pattern. After all, design patterns are some templates that can help improve the efficiency of development summarized and extracted by seniors, which come from daily development.

In fact, adapters should be quite common in JavaScript.

In Wikipedia, the definition of adapter patterns is:

In software engineering, the adapter pattern is a software design pattern that allows the interface of an existing class to be used from another interface. It is often used to make existing classes work with other classes without modifying their source code.

Examples in life

The most common thing in life is the adapter of the power plug. The standards of sockets vary from country to country. If you need to buy the corresponding power plug according to the standard of each country, it is too much waste of money. If you take the socket with you, it is certainly unrealistic to break the wall and rewire it.

So there will be an adapter for the plug, which is used to convert one plug into another, and the thing that transfers between the socket and your power supply is the adapter.

Reflected in the code

When it comes to programming, I personally understand it like this:

Hide the dirty code you don't want to see, and you can say it's an adapter.

Access to multiple third-party SDK

To take an example in daily development, we are doing a Wechat official account development, in which we use Wechat's payment module. After a long period of joint adjustment, we finally got through the whole process. Just when you are ready to happily pack the launch code, we have a new requirement:

We need to connect to the SDK of Alipay official account and have a payment process.

To reuse the code, we might write this logic in the script:

If (platform = = 'wechat') {wx.pay (config)} else if (platform =' alipay') {alipay.pay (config)} / / do some subsequent logic processing

But generally speaking, the interface calls provided by the SDK of each factory will be more or less different, although sometimes the same document may be used to pay homage to the competitors.

So for the above code, it might look like this:

/ / it is not a real parameter configuration Just for example, using const config = {price: 10, goodsId: 1} / / it is possible to return values differently if (platform = 'wechat') {config.appId =' XXX' config.secretKey = 'XXX' wx.pay (config) .then ((err) Data) = > {if (err) / / error / / success})} else if (platform = 'alipay') {config.token =' XXX' alipay.pay (config, data = > {/ / success}, err = > {/ / error})}

For now, the code interface is clear, and as long as we write comments, it's not too bad code.

But life is always full of surprises, and we have received SDK that need to add QQ, SDK of Meituan, SDK of Xiaomi, or SDK of some banks.

At this point, your code might look like this:

Switch (platform) {case 'wechat': / / Wechat processing logic break case' QQ': / / QQ processing logic break case 'alipay': / / Alipay processing logic break case' meituan': / / Meituan processing logic break case 'xiaomi': / / Xiaomi processing logic break}

This is no longer a problem that some comments can make up for, such code will become more and more difficult to maintain, all kinds of strange ways to call SDK, if others want to do similar requirements, but also need to rewrite such code, it must be a waste of resources.

So in order to ensure the clarity of our business logic, and to avoid future generations from repeatedly stepping on this hole, we will split it out as a common function:

Find out how to call one of the SDK or a rule we agreed on as a benchmark.

Let's tell the caller what you're going to do, how you can get the returned data, and then we make all these dirty judgments inside the function:

Function pay ({price, goodsId}) {return new Promise ((resolve, reject) = > {const config = {} switch (platform) {case 'wechat': / / Wechat processing logic config.price = price config.goodsId = goodsId config.appId =' XXX' config.secretKey = 'XXX' wx.pay (config). Then ((err) Data) = > {if (err) return reject (err) resolve (data)}) the processing logic of break case 'QQ': / / QQ config.price = price * 100 config.gid = goodsId config.appId =' XXX' config.secretKey = 'XXX' config.success = resolve Config.error = reject qq.pay (config) break case 'alipay': / / the processing logic of Alipay config.payment = price config.id = goodsId config.token =' XXX' alipay.pay (config) Resolve, reject) break}})}

In this way, no matter what environment we are in, as long as our adapter supports it, we can call according to the general rules we agreed upon, and what kind of SDK is executed is what the adapter needs to care about:

/ / run anywhere await pay ({price: 10, goodsId: 1})

For the SDK provider, you only need to know some of the parameters you need, and then return the data in your own way.

For the SDK calling room, we only need to agree on the common parameters and monitor the callback in the agreed manner.

The task of integrating multiple third-party SDK is left to the adapter, and then the code of the adapter is compressed, confused, and placed in an invisible corner, and the code logic becomes clear:).

This is roughly what the adapter does. One thing must be clear: the adapter is not a silver bullet. The tedious code always exists. It's just that you can't see it when you write your business.

Some other examples

Personally, there are many examples of adapters in jQuery, including the most basic $('selector'). On, isn't this an obvious adapter pattern?

Downgrade step by step, and smooth out some differences between browsers, so that we can listen to events in mainstream browsers through simple on:

/ / A simple pseudocode example function on (target, event, callback) {if (target.addEventListener) {/ / Standard listening event mode target.addEventListener (event, callback)} else if (target.attachEvent) {/ / IE low version listening mode target.attachEvent (event) Callback)} else {/ / some low-version browsers listen for events target [`on$ {event} `] = callback}}

Or such an example in Node is more common, because in the early years there was no Promise, so most asynchronism is done by callback, and there is an agreed rule, Error-first callback:

Const fs = require ('fs') fs.readFile (' test.txt', (err, data) = > {if (err) / / handle exceptions / / handle correct results})

And our new functions are carried out in the way of async/await, when we need to reuse some functions in the old project, it is certainly not feasible to modify the code of the old project directly.

Such compatibility processing needs to be done by the caller, so in order to make the logic code look less messy, we may convert this callback to a version of Promise that makes it easier for us to call:

Const fs = require ('fs') function readFile (fileName) {return new Promise ((resolve, reject) = > {fs.readFile (fileName, (err, data) = > {if (err) reject (err) resolve (data)})} await readFile (' test.txt')

As mentioned earlier, this Error-first callback is an agreed form, so we can easily implement a general-purpose adapter:

Function promisify (func) {return (... args) = > new Promise ((resolve, reject) = > {func (... args, (err, data) = > {if (err) reject (err) resolve (data)}

Then perform the corresponding transformation before using it to execute the code in the way we expect:

Const fs = require ('fs') const readFile = promisify (fs.readFile) await readFile (' test.txt')

In Node8, officials have implemented a tool function like this: util.promisify

Personal point of view: all design patterns are not imagined out of thin air, but must be summarized and refined in the process of development, which means that you may not need to eat these high-end design patterns at the beginning.

Because the scenarios described in the book may not be comprehensive, or there may be better solutions for some languages, copying mechanically may not produce code with a soul.

The above is how the adapter is reflected in JavaScript, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.