设计模式---适配器模式

适配器模式

将一个类的接口转换成客户期望的另一个接口，使得原本的接口不兼容的类可以一起工作，结构型设计模式.

适用场景

适配器模式不是设计阶段考虑使用的设计模式，随着软件维护由于接口不相同下的解决方案.

适配器分类

《Head First 设计模式》中提到适配器分为两类：对象适配器，类适配器，此外还有一种==接口适配器==.

对象适配器：使用组合的方式，假设我们需要调用的目标是接口，但是现有的类/接口和目标接口不兼容，我们需要一个==适配器==实现目标接口，并且持有被适配接口/类对象。

类适配器：类适配器在《Head First 设计模式》中原来指多继承，但是java中，指采用继承的方式，实现目标接口同时继承被适配类，这样继续使用接口的形式调用适配器，从而无感知达到目的。但是如果被适配类不可知因素过多，使用起来可能继承效果不如组合来得方便，我的理解假如被适配的类都是通过Spring实例化的，那就有点麻烦了.

接口适配器：接口适配器区别于前面两种，假如一个接口很庞大，我们每次写一个实现类都需要实现所有方法，然后只改写我们用到一两个方法，那代码看起来也会很臃肿，于是就有了接口适配器。使用抽象类实现接口的所有方法，抽象类实现的接口方法全部是空方法，当新需要一个子类时候，继承抽象类并且只重写特定的方法即可。

简单案例

前几天去了香港，住宿一晚发现，香港电压和内陆是一样的220V，50HZ，但是我们不能直接在插头插上充电线来给手机充电，香港法律规定室内电器插头都是英式的方脚三柱插头，内陆的插头都是两脚插头，像手机充电线插头都是两个平行的脚，这时候使用酒店提供的转换器就可以正常使用充电线了，转换器就像是适配器。这就是对象适配器的一个小例子，内陆标准的充电插头规范(双平行脚)就是我们的目标接口，但是在香港室内都没有这种提供使用的双脚的充电插槽，转换器就是适配器，实现了国内插头标准，因为它有双脚插槽，同时它还组合的三角的充电插槽，无缝衔接.

//国内常见插头接口规范
public interface DoublePin {
    void chargeForDoublePin();
}
//适配器
public class PluginAdaptor implements DoublePin {
    private TripplePin tripplePin;

    public PluginAdaptor(final TripplePin tripplePin) {
        this.tripplePin = tripplePin;
    }

    @Override
    public void chargeForDoublePin() {
        tripplePin.chargeForThreePinOnly();
    }
}
//香港以及以外的插头规范
public class TripplePin {
    void chargeForThreePinOnly(){
        System.out.println("充电中......");
    }
}

测试类PersonTests

public class PersonTests {
    public static void main(String[] args) {
        TripplePin hotelPlugin = new TripplePin();
        DoublePin myChargeLine=new PluginAdaptor(hotelPlugin);
        myChargeLine.chargeForDoublePin();
    }
}

讲解：适配器的目的相当于中间人，中间人肯定要知道有两方信息吧，对象适配器特征：实现目标接口，持有另外一方联系；

类适配器的例子

public class PluginAdaptor2 extends TripplePin implements DoublePin {

    @Override
    public void chargeForDoublePin() {
        chargeForThreePinOnly();
    }

}

讲解：上面适配器的代码稍作改动就是类适配器的例子，不同之处就是采用继承的方式作为中间人，如果说酒店转换头是组合的方式，那继承就好比把方脚三柱插头和转换头包裹严实起来，只留个双脚的插槽暴露出来，我们可能感知下来：噢，香港和国内充电没有区别，充电线带过去一样使用。

接口适配器的例子

java.awt包中的WindowListener接口定义了几个窗口的监听事件，WindowAdapter实现了接口，但是方法全都是空实现的，如果我们需要关闭窗口时做额外处理，完全一个匿名内部类并且重写windowClosed方法即可，代码简洁且效果一样，(以前写awt就没搞明白windowClosing、windowClosed区别是啥)

image

优点

提高类的透明性以及复用，低耦合，有利于程序扩展；符合开闭

Spring中的适配器

以下是第一次读Spring源码之后对于适配器模式的理解。Spring中有很多Adapter为后缀的类，上面几种形式的适配器很常见对象适配器ConverterAdapter，接口适配器InstantiationAwareBeanPostProcessorAdapter、HandlerInterceptorAdapter，当然这些适配器每个作用不相同需要结合源码分析，这里就不记录了，至于==HandlerAdapter==、==AvisorAdapter==我感觉不像是适配器模式，但是是否使用了什么适配器还不太清楚.

==HandlerAdapter== 理解：名称叫处理器适配器，在SpringMvc中的作用呢找到那个 HandlerAdapter ，然后就是处理请求。我觉得更像是一种适配，而不是适配器模式，也有人说这更像命令模式，。前面记录的适配器模式是将一个接口转换为另一个不兼容的接口，供客户端调用；先说没有==HandlerAdapter==的话该是怎么处理：

得到mapperHandler.getHandler，之后判断他是个HttpRequestHandler还是HandlerMethod等等，进行大量IF ELSE 的逻辑处理，如果我们在框架基础上修改就需要改动源码，不符合开闭原则。现在就是将所有的 HandlerAdapter实现类放到集合中，调support(handler)来判断是否支持，之后仅仅用这个HandlerAdapter去反射执行控制器的方法；

纠结了好久，换个角度想我的目标是调用这个处理器的方法，我们假设存在这样一个接口unamed，这个接口呢用来动态判断处理器类型并且反射调用；而另一个不兼容的类就是HandlerAdapter的各种实现类(比如SimpleServletHandlerAdapter 我们完全可以写个任意名字方法调用 handle.service(request,response)； ) ，现在需要将这个unamed接口和各个不兼容的类实现适配，我会写个类去实现 unamed接口，然后实现handle方法，但是组合的对象变成 HandlerAdapter，并且HandlerAdapter是在每次调用这个接口实现类的handle方法之前去动态初始化.

下面这个看起来更是适配器模式了吧，但是下面的代码完全没必要，看起来累赘而且完全没必要。

public interface Unamed {
    ModelAndView handle1(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
}

public class UnamedImpl implements Unamed{
    private HandlerAdapter ha;
    @Override
    public ModelAndView handle1(final HttpServletRequest request, final HttpServletResponse response, final Object handler) throws Exception {
        ha=getHandler();
        return ha.handle(request,response,handler);
    }

     private HandlerAdapter getHandler() {
        //略
         return  null;
     }
 }