适配器模式
适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。
这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。
介绍
意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
主要解决：主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。
何时使用：
1、系统需要使用现有的类，而此类的接口不符合系统的需要。
2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。 3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）
如何解决：继承或依赖（推荐）。
关键代码：适配器继承或依赖已有的对象，实现想要的目标接口。
应用实例： 1、美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。
优点： 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。
缺点： 1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。
使用场景：有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。
注意事项：适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。
应用场景
适配器模式（AdapterPattern）是指将一个类的接口转换成客户期望的另一个接口，使原本的接口不兼容的类可以一起工作，属于结构型设计模式。
适配器适用于以下几种业务场景：
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 outoupDC5V();
}
创建电源适配器PowerAdapter类：
public class PowerAdapter implements DC5 {
private AC220 ac220;
public PowerAdapter(AC220 ac220) {
this.ac220 = ac220;
}
public int outoupDC5V() {
int adapterInput = ac220.outputAC220V();
int adapterOutput = adapterInput / 44;
System.out.println("使用PowerAdapter输入AC:" + adapterInput + "V,输出DC：" + adapterOutput + "V");
return adapterOutput;
}
}
客户端测试代码：
public class PowerAdapterTest {
public static void main(String[] args) {
DC5 dc5 = new PowerAdapter(new AC220());
dc5.outoupDC5V();
}
}
上面的案例中，通过增加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 {
/**
* 注册方法
* @param username
* @param password
* @return
*/
public ResultMsg regist(String username,String password){
return new ResultMsg(200,"注册成功",new Member());
}
/**
* 登录的方法
* @param username
* @param password
* @return
*/
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 SinginForThirdService 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 SiginForThirdServiceTest {
public static void main(String[] args) {
SinginForThirdService service = new SinginForThirdService();
service.login("tom","123456");
service.loginForQQ("sdfasdfasf");
service.loginForWechat("sdfasfsa");
}
}
通过这么一个简单的适配，完成了代码兼容。当然，我们代码还可以更加优雅，根据不同的登录方式，创建不同的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登录
* @param id
* @return
*/
ResultMsg loginForQQ(String id);
/**
* 微信登录
* @param id
* @return
*/
ResultMsg loginForWechat(String id);
/**
* 记住登录状态后自动登录
* @param token
* @return
*/
ResultMsg loginForToken(String token);
/**
* 手机号登录
* @param telphone
* @param code
* @return
*/
ResultMsg loginForTelphone(String telphone, String code);
/**
* 注册后自动登录
* @param username
* @param passport
* @return
*/
ResultMsg loginForRegist(String username, String passport);
}
实现兼容PassportForThirdAdapter：
/**
* 结合策略模式、工厂模式、适配器模式
*/
public class PassportForThirdAdapter extends SiginService implements IPassportForThird {
public ResultMsg loginForQQ(String id) {
// return processLogin(id,RegistForQQAdapter.class);
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,passport);
return super.login(username,passport);
}
private ResultMsg processLogin(String key,Class clazz){
try{
//适配器不一定要实现接口
LoginAdapter adapter = clazz.newInstance();
//判断传过来的适配器是否能处理指定的逻辑
if(adapter.support(adapter)){
return adapter.login(key,adapter);
}
}catch (Exception e){
e.printStackTrace();
}
return null;
}
//类图的快捷键 Ctrl + Alt + Shift + U
}
客户端测试代码：
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的源代码：
public interface AdvisorAdapter {
boolean supportsAdvice(Advice advice);
MethodInterceptor getInterceptor(Advisor advisor);
}
再看MethodBeforeAdviceAdapter类：
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
@Override
public boolean supportsAdvice(Advice advice) {
return (advice instanceof MethodBeforeAdvice);
}
@Override
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 {
ModelAndView mv = null;
Exception dispatchException = null;
try {
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = "GET".equals(method);
if (isGet || "HEAD".equals(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (logger.isDebugEnabled()) {
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;
}
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
catch (Throwable err) {
// As of 4.3, we're processing Errors thrown from handler methods as well,
// making them available for @ExceptionHandler methods and other scenarios.
dispatchException = new NestedServletException("Handler dispatch failed", err);
}
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Throwable err) {
triggerAfterCompletion(processedRequest, response, mappedHandler,
new NestedServletException("Handler processing failed", err));
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
}
else {
// Clean up any resources used by a multipart request.
if (multipartRequestParsed) {
cleanupMultipart(processedRequest);
}
}
}
}
在doDispatch()方法中调用了getHandlerAdapter()方法，来看代码：
protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
if (this.handlerAdapters != null) {
for (HandlerAdapter ha : this.handlerAdapters) {
if (logger.isTraceEnabled()) {
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又是在初始化时早已赋值。这里我们不再深入，后面的源码专题中还会继续讲解。
一些信息
路漫漫其修远兮,吾将上下而求索
码云：https://gitee.com/javacoo
QQ群：164863067
作者/微信：javacoo
邮箱：[email protected]