结构型设计模式之适配器模式

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第11天，点击查看活动详情

见文知意

什么是适配器模式呢？

适配器模式：将一个类（对象）的接口（方法或者属性）转化为另外一个接口，满足用户需求，使类（对象）之间接口的不同兼容性问题得以适配。

更通俗的说，适配器模式其实就是一个接口转换器。举个例子，大家现在安卓手机大多数是Type-C接口的，而部分耳机的插头是圆孔的，这个时候我们就会通过买个接口转化器来插入Type-C接口，将耳机插头插入到接口转换器上，这其实就是我们说的适配器。适配器模式在代码中的作用就相当于接口转换器。

适配器模式探索

参数适配器

适配器模式的一个比较好用的场景就是参数适配。当我们封装一个第三方插件库的时候，随着我们功能的复杂，初始化参数逐渐增多，例如：

    function init(name, title, id, type, executor) {
        ...
    }

对于使用者来说，这是很不友好的。使用者需要花费大量的精力来借助参数的顺序以及对应的值的意义，所以为了降低参数复杂度，我们通常将这些参数整合到一个object对象中。

    function init (initData) {
        ...
    }

对于使用者来说，方便了，只需要传入需要使用的参数的值即可，对于其它使用不到的参数使用默认值就可以了。这个时候对于我们开发者来说，就需要对于必填参数进行非空校验，对于非必填参数进行默认值设置等。

这个时候，适配器模式就很香了。看过一些插接库的源代码的小伙伴可能见到过这种设计模式的应用。

    function init (initData) {
        const flyData = Object.assign({}, defaultData, initData);
        ...
    }

接口适配器

对于开发经验丰富的小伙伴来说，会经常进行数据视图层和逻辑层的解耦。之所以这样做的一个原因是为了摆脱服务都接口数据对前端渲染的制约。比方说：

对于同一个接口，服务端之前返回的数据格式是这样的，过了一段时间，业务需求发生了变更导致服务端接口返回的数据格式发生了变化，这时候就需要前端页面跟着就行调整，否则页面就会无法正常渲染出来。

这个时候，其实我们可以用到适配器模式，在逻辑层对服务端数据进行一次整合处理，返回跟之前数据结构一致的数据就可以保证视图层正常渲染了。

伪代码大约如下：

    function adapterData(data) {
        // 处理数据格式，并返回期望的数据结构
        ...
    }

    function getOrderList () {
        axios.get(url, params)
            .then((res) => {
                if (res.data) {
                    return adapterData(res.data);
                }
            });
    }

总结

适配器模式更多的是应用于抹平数据差异，方便我们对数据进行使用，虽然增加了一些资源开销，但是基本可以忽略不计，而且带来的好处是非常可观的。所以碰到这种场景我们会很自然的使用适配器模式进行处理。

好的，有关适配器模式我们就聊到这里了，欢迎大家在下方进行留言交流。