适配器(adapter)模式在JS中实践

适配器(adapter)模式

定义

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

        换句话说，就是我用我的接口，但是还是用你的服务。

举个例子：

        有一天你从香港买来一个iphone8，但是香港的插头要比大陆地区的插头大一些，你回到家之后发现在现有的屋子环境下找不到合适的插口能够插入这个插头。现在有两个办法，一是：更换屋里的所有的或者部分插口能够插下iphone8，但是这个行不通的，家是在大陆，一般电器插口还是国标的，虽然解决了我一时需要使用ip8，但是手机更换这么快很可能我下一次就从大陆地区买ip10了，要是更换屋子的插口，岂不是还要更换回来？。二是：由于iphone8对于我这个屋子来说是临时用品，所以不会改变屋子的现状，而是从香港苹果官网（公司）上买一个港标转国标的适配器，只是在ip8插头上接上这个适配器就可以使用屋子里的插口了，并且这个适配器还有变压的功能。

我们对这个例子进行抽象下：

1. 屋子：相当于稳定的业务代码或者上层逻辑，或者说是已经发布部署好了的产品。
2. iphone8：相当于 变化的需求，不稳定，随时变化
3. 香港的插头要比大陆地区的插头大：需求变化带来的问题。
4. 港标转国标的适配器：解决上述需求的方式
5. 香港苹果官网/苹果公司： 适配器需要被上层业务管理，而不是下层底层实现。

        在一开始设计业务代码/实现上层逻辑（在建房子的时候）不会去考虑为了能够适应我以后要买港货而设计一个插口，这种设计师很扯淡的，没有人有准确预测风险的能力。这总需求的变化总是出现在上层业务实现好了的基础上的，如果说出现了需求变化（ip8出现）去改动上层业务代码也是不现实的，因为对上层业务代码更改很复杂不说，一旦改动，就要重新测试、维护、部署浪费了大量时间花在不相关的工作上，更何况这个需求以后肯定还变化。那么最好的方式就是在上层业务外部使用一种adapter能够将这个需求进行包装是便于适应我现有的业务。那么适配器是最好不过的了。但是这个适配器必须是由需求变化的一方（香港苹果公司）生产只有这样才能保证适配器的标准。

        适配器的定义就介绍到这里，接下来看看如果从一个上层业务已经写好了的情况下去适应变化的需求，这个需求问题在于接口不能应用到业务代码中。

adapter产生过程

        由于设计模式一