Adapter（适配器模式）

适配器就是一种适配中间件，它存在于不匹配的二者之间，用于连接二者，将不匹配变得匹配，简单点理解就是平常所见的转接头，转换器之类的存在。

生活场景

我有一台MAC电脑，他只有type-c口（未来的统一接口）。

我有一个硬盘但他只有USB口

现在我想把硬盘中的数据，转到我的mac电脑上怎么办？

我必须去买一个中间适配器进行数据的传输转换。

这个例子中：硬盘可以看作一个系统，MAC是另一个系统。二者之间存在不匹配，而我们的适配器的作用就是连接二者。

JDK场景

例如：java.io.InputStreamReader

1.该类继承了Read（字符流）类，我们的目标系统只会处理字符流的。

2.创建它的对象必须在构造函数中传入一个InputStream（字节流），我们的来源系统是产出字节流的。

所以作为适配器InputStreamReader 只会出现在，我们现在想要字符流，但现在却只有字节流

业务理解

适配器往大的说，可以是2系统对接。现在流行的SOA服务

例如：底层SOA系统提供出来的接口不一定是各各业务系统想要的。（适配类写在业务系统）

//来源系统（模块，层级）所能提供的
    static interface  source{
        String get();
    }

    //我将要使用的
    static interface target{
       Integer get();
    }

    //我的适配器
    static class Adapter implements target{

        private source s;

        public Adapter(source s) {
            this.s = s;
        }

        public Integer get(){
            return Integer.parseInt(s.get());
        }
    }

例如：底层业务系统想重构，但不想影响各各业务系统。（适配类写在底层系统）

往小的说可以当信上个工具类：

例如：java.io.InputStreamReader

总结

系统架构时，要预留适配器可出现的空间。而适配器出现的地方是模块和模块之间，系统和系统之间，层级与层级之间。

现在spring的各开源框架基本上都是面向接口的。而接口的设计给适配器已带了了充分的方便。

认真对待每一行代码，他可能毁了适配的可能。