适配器模式

适配器模式的应用场景

适配器模式（Adapter Pattern）是指将一个类的接口转换成客户期望的另一个接口，使原本的接口不兼容的类可以一起工作，属于结构型设计模式。

适配器适用于以下几种业务场景：

1. 已经存在的类，它的方法和需求不匹配（方法结果相同或相似）的情况。
2. 适配器模式不是软件设计阶段考虑的设计模式，是随着软件维护，由于不同产品、不同厂家造成功能类似而接口不相同情况下的解决方案。有点亡羊补牢的感觉。

生活中也非常的应用场景，例如电源插转换头、手机充电转换头、显示器转接头。

在中国民用电都是 220V 交流电，但我们手机使用的锂电池使用的 5V 直流电。因此，我们给手机充电时就需要使用电源适配器来进行转换。下面我们有代码来还原这个生活场景，创建 AC220 类，表示 220V 交流电：

public class AC220 {
    public int outputAC220V(){
        int output = 220;
        System.out.println("输出交流电"+output+"V");
        return output;
    }
}

创建 DC5 接口，表示 5V 直流电的标准：

public interface DC5 {
    int outputDC5V();
}

创建电源适配器 PowerAdapter 类：

public class PowerAdapter implements DC5{
    private AC220 ac220;
    public PowerAdapter(AC220 ac220){
        this.ac220 = ac220;
    }
    public int outputDC5V() {
        int adapterInput = ac220.outputAC220V();
        //变压器...
        int adapterOutput = adapterInput/44;
        System.out.println("使用 PowerAdapter 输入 AC:"+adapterInput+"V"+"输出 DC:"+adapterOutput+"V");
        return adapterOutput;
    }
}

客户端测试代码：

public class ObjectAdapterTest {
    public static void main(String[] args) {
        DC5 dc5 = new PowerAdapter(new AC220());
        dc5.outputDC5V();
    }
}

上面的案例中，通过增加 PowerAdapter 电源适配器，实现了二者的兼容。

重构第三方登录自由适配

下面我们来一个实际的业务场景，利用适配模式来解决实际问题。年纪稍微大一点的小伙伴一定经历过这样一个过程。我们很早以前开发的老系统应该都有登录接口，但是随着业务的发展和社会的进步，单纯地依赖用户名密码登录显然不能满足用户需求了。现在，我们大部分系统都已经支持多种登录方式，如 QQ 登录、微信登录、手机登录、微博登录等等，同时保留用户名密码的登录方式。虽然登录形式丰富了，但是登录后的处理逻辑可以不必改，同样是将登录状态保存到 session，遵循开闭原则。

首先创建统一的返回结果 ResultMsg 类：

public class ResultMsg {
    private int code;
    private String msg;
    private Object data;
    public ResultMsg(int code, String msg, Object data) {
        this.code = code;
        this.msg = msg;
        this.data = data;
    }
    public int getCode() {
        return code;
    }
    public void setCode(int code) {
        this.code = code;
    }
    public String getMsg() {
        return msg;
    }
    public void setMsg(String msg) {
        this.msg = msg;
    }
    public Object getData() {
        return data;
    }
    public void setData(Object data) {
        this.data = data;
    }
}

假设老系统的登录逻辑 SiginService：

public class SiginService {
    /**
     * 注册方法
     */
    public ResultMsg regist(String username, String password) {
        return new ResultMsg(200, "注册成功", new Member());
    }

    /**
     * 登录的方法
     */
    public ResultMsg login(String username, String password) {
        return null;
    }
}

为了遵循开闭原则，老系统的代码我们不会去修改。那么下面开启代码重构之路，先创建 Member 类：

public class Member {
    private String username;
    private String password;
    private String mid;
    private String info;
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String getPassword() {
        return password;
    }
    public void setPassword(String password) {
        this.password = password;
    }
    public String getMid() {
        return mid;
    }
    public void setMid(String mid) {
        this.mid = mid;
    }
    public String getInfo() {
        return info;
    }
    public void setInfo(String info) {
        this.info = info;
    }
}

创建一个新的类继承原来的逻辑，运行非常稳定的代码我们不去改动：

public class SigninForThirdService extends SiginService {
    public ResultMsg loginForQQ(String openId){
        //1、openId 是全局唯一，我们可以把它当做是一个用户名(加长)
        //2、密码默认为 QQ_EMPTY
        //3、注册（在原有系统里面创建一个用户）
        //4、调用原来的登录方法
        return loginForRegist(openId,null);
    }
    public ResultMsg loginForWechat(String openId){
        return null;
    }
    public ResultMsg loginForToken(String token){
        //通过 token 拿到用户信息，然后再重新登陆了一次
        return null;
    }
    public ResultMsg loginForTelphone(String telphone,String code){
        return null;
    }
    public ResultMsg loginForRegist(String username,String password){
        super.regist(username,null);
        return super.login(username,null);
    }
}

客户端测试代码：

public class SigninForThirdServiceTest {
    public static void main(String[] args) {
        SigninForThirdService service = new SigninForThirdService();
        //不改变原来的代码，也要能够兼容新的需求
        //还可以再加一层策略模式
        service.loginForQQ("sdfgdgfwresdf9123sdf");
    }
}

通过这么一个简单的适配，完成了代码兼容。当然，我们代码还可以更加优雅，根据不同的登录方式，创建不同的 Adapter。首先，创建 LoginAdapter 接口：

public interface LoginAdapter {
    boolean support(Object adapter);
    ResultMsg login(String id,Object adapter);
}

分别实现不同的登录适配，QQ 登录 LoginForQQAdapter：

public class LoginForQQAdapter implements LoginAdapter {
    public boolean support(Object adapter) {
        return adapter instanceof LoginForQQAdapter;
    }
    public ResultMsg login(String id, Object adapter) {
        return null;
    }
}

新浪微博登录 LoginForSinaAdapter：

public class LoginForSinaAdapter implements LoginAdapter {
    public boolean support(Object adapter) {
        return adapter instanceof LoginForSinaAdapter;
    }
    public ResultMsg login(String id, Object adapter) {
        return null;
    }
}

手机号登录 LoginForTelAdapter：

public class LoginForTelAdapter implements LoginAdapter {
    public boolean support(Object adapter) {
        return adapter instanceof LoginForTelAdapter;
    }
    public ResultMsg login(String id, Object adapter) {
        return null;
    }
}

Token 自动登录 LoginForTokenAdapter:

public class LoginForTokenAdapter implements LoginAdapter {
    public boolean support(Object adapter) {
        return adapter instanceof LoginForTokenAdapter;
    }
    public ResultMsg login(String id, Object adapter) {
        return null;
    }
}

微信登录 LoginForWechatAdapter：

public class LoginForWechatAdapter implements LoginAdapter {
    public boolean support(Object adapter) {
        return adapter instanceof LoginForWechatAdapter;
    }
    public ResultMsg login(String id, Object adapter) {
        return null;
    }
}

然后，创建第三方登录兼容接口 IPassportForThird:

public interface IPassportForThird {
    /**
     * QQ 登录
     */
    ResultMsg loginForQQ(String id);

    /**
     * 微信登录
     */
    ResultMsg loginForWechat(String id);

    /**
     * 记住登录状态后自动登录
     */
    ResultMsg loginForToken(String token);

    /**
     * 手机号登录
     */
    ResultMsg loginForTelphone(String telphone, String code);

    /**
     * 注册后自动登录
     */
    ResultMsg loginForRegist(String username, String passport);
}

实现兼容 PassportForThirdAdapter：

/**
 * 第三方登录自由适配
 */
public class PassportForThirdAdapter extends SiginService implements IPassportForThird {
    public ResultMsg loginForQQ(String id) {
        return processLogin(id,LoginForQQAdapter.class);
    }
    public ResultMsg loginForWechat(String id) {
        return processLogin(id,LoginForWechatAdapter.class);
    }
    public ResultMsg loginForToken(String token) {
        return processLogin(token,LoginForTokenAdapter.class);
    }
    public ResultMsg loginForTelphone(String telphone, String code) {
        return processLogin(telphone,LoginForTelAdapter.class);
    }
    public ResultMsg loginForRegist(String username, String passport) {
        super.regist(username,null);
        return super.login(username,null);
    }
    //这里用到了简单工厂模式及策略模式
    private ResultMsg processLogin(String key,Class<? extends LoginAdapter> clazz){
        try {
            LoginAdapter adapter = clazz.newInstance();
            if(adapter.support(adapter)) {
                return adapter.login(key, adapter);
            }else {
                return null;
            }
        }catch (Exception e){
            e.printStackTrace();;
        }
        return null;
    }
}

客户端测试代码：

public class PassportTest {
    public static void main(String[] args) {
        IPassportForThird passportForThird = new PassportForThirdAdapter();
        passportForThird.loginForQQ("");
    }
}

最后，来看一下类图：

至此，我们在遵循开闭原则的前提下，完整地实现了一个兼容多平台登录的业务场景。
当然，我目前的这个设计也并不完美，仅供参考，感兴趣的小伙伴可以继续完善这段代码。例如适配器中的参数目前是写死为 String，改为 Object[]应该更合理。

学习到这里，相信小伙伴会有一个疑问了：适配器模式跟策略模式好像区别不大？在这里我要强调一下，适配器模式主要解决的是功能兼容问题，单场景适配大家可能不会和策略模式有对比。但多场景适配大家产生联想和混淆了。其实，大家有没有发现一个细节，我给每个适配器都加上了一个 support()方法，用来判断是否兼容，support()方法的参数也是 Object 的，而 supoort()来自于接口。适配器的实现逻辑并不依赖于接口，我们完全可以将 LoginAdapter 接口去掉。而加上接口，只是为了代码规范。上面的代码可以说是策略模式、简单工厂模式和适配器模式的综合运用。

适配器模式在源码中的体现

Spring 中适配器模式也应用得非常广泛，例如：SpringAOP 中的 AdvisorAdapter 类，它有三个实现类 MethodBeforeAdviceAdapter、AfterReturningAdviceAdapter 和 ThrowsAdviceAdapter，先来看顶层接口 AdvisorAdapter 的源代码：

package org.springframework.aop.framework.adapter;
import org.aopalliance.aop.Advice;
import org.aopalliance.intercept.MethodInterceptor;
import org.springframework.aop.Advisor;
public interface AdvisorAdapter {
    boolean supportsAdvice(Advice var1);
    MethodInterceptor getInterceptor(Advisor var1);
}

再看 MethodBeforeAdviceAdapter 类：

package org.springframework.aop.framework.adapter;
import java.io.Serializable;
import org.aopalliance.aop.Advice;
import org.aopalliance.intercept.MethodInterceptor;
import org.springframework.aop.Advisor;
import org.springframework.aop.MethodBeforeAdvice;
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
    MethodBeforeAdviceAdapter() {
    }
    public boolean supportsAdvice(Advice advice) {
        return advice instanceof MethodBeforeAdvice;
    }
    public MethodInterceptor getInterceptor(Advisor advisor) {
        MethodBeforeAdvice advice = (MethodBeforeAdvice)advisor.getAdvice();
        return new MethodBeforeAdviceInterceptor(advice);
    }
}

其它两个类我这里就不把代码贴出来了。Spring 会根据不同的 AOP 配置来确定使用对应的 Advice，跟策略模式不同的一个方法可以同时拥有多个 Advice。
下面再来看一个 SpringMVC 中的 HandlerAdapter 类，它也有多个子类，类图如下：

其适配调用的关键代码还是在 DispatcherServlet 的 doDispatch()方法中，下面我们还是来看源码：

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception{
    HttpServletRequest processedRequest = request;
    HandlerExecutionChain mappedHandler = null;
    boolean multipartRequestParsed = false;
    WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
    try {
        try {
            ModelAndView mv = null;
            Object dispatchException = null;
            try {
                processedRequest = this.checkMultipart(request);
                multipartRequestParsed = processedRequest != request;
                mappedHandler = this.getHandler(processedRequest);
                if(mappedHandler == null) {
                    this.noHandlerFound(processedRequest, response);
                    return;
                }
                HandlerAdapter ha = this.getHandlerAdapter(mappedHandler.getHandler());
                String method = request.getMethod();
                boolean isGet = "GET".equals(method);
                if(isGet || "HEAD".equals(method)) {
                    long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
                    if(this.logger.isDebugEnabled()) {
                        this.logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);
                    }
                    if((new ServletWebRequest(request, response)).checkNotModified(lastModified) && isGet) {
                        return;
                    }
                }
                if(!mappedHandler.applyPreHandle(processedRequest, response)) {
                    return;
                }
                mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
                if(asyncManager.isConcurrentHandlingStarted()) {
                    return;
                }
                this.applyDefaultViewName(processedRequest, mv);
                mappedHandler.applyPostHandle(processedRequest, response, mv);
            } catch (Exception var20) {
                dispatchException = var20;
            } catch (Throwable var21) {
                dispatchException = new NestedServletException("Handler dispatch failed", var21);
            }
            this.processDispatchResult(processedRequest, response, mappedHandler, mv,
                                       (Exception)dispatchException);
        } catch (Exception var22) {
            this.triggerAfterCompletion(processedRequest, response, mappedHandler, var22);
        } catch (Throwable var23) {
            this.triggerAfterCompletion(processedRequest, response, mappedHandler, new NestedServletException("Handler processing failed", var23));
        }
    } finally {
        if(asyncManager.isConcurrentHandlingStarted()) {
            if(mappedHandler != null) {
                mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
            }
        } else if(multipartRequestParsed) {
            this.cleanupMultipart(processedRequest);
        }
    }
}

在 doDispatch() 方法中调用了 getHandlerAdapter() 方法，来看代码：

protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
    if(this.handlerAdapters != null) {
        Iterator var2 = this.handlerAdapters.iterator();
        while(var2.hasNext()) {
            HandlerAdapter ha = (HandlerAdapter)var2.next();
            if(this.logger.isTraceEnabled()) {
                this.logger.trace("Testing handler adapter [" + ha + "]");
            }
            if(ha.supports(handler)) {
                return ha;
            }
        }
    }
    throw new ServletException("No adapter for handler [" + handler + "]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler");
}

在 getHandlerAdapter()方法中循环调用了 supports()方法判断是否兼容，循环迭代集合中的 Adapter 又是在初始化时早已赋值。这里我们不再深入，后面的源码专题中还会继续讲解。

适配器模式的优缺点

优点：

1. 能提高类的透明性和复用，现有的类复用但不需要改变。

2. 目标类和适配器类解耦，提高程序的扩展性。

3. 在很多业务场景中符合开闭原则。

缺点：

1. 适配器编写过程需要全面考虑，可能会增加系统的复杂性。
2. 增加代码阅读难度，降低代码可读性，过多使用适配器会使系统代码变得凌乱。