生活中经常出现两个“事物”不能直接匹配,需要中间加一层转换层实现原本不兼容的接口或者规范变得通用。例如我们使用的各种电源适配器,还例如我前段时间更换电脑的SSD,应因新的SSD与老的不兼容,中间加了个转换头等等。
在程序软件世界中,同样存在着此问题。我们需要使用某些成熟的组件,但是接口或者方法定义又使得我们无法直接使用,而又不能去修改运行稳定的代码。重新开发的话成本和代价都很高,这可以通过中间加一层适配层来转换组件与新使用方的关系,从而达到复用组件的目的。这就是今天所要说到的适配器模式在软件设计领域的使用,很多开源框架中也经常能够看到。
模式的定义与特点
适配器模式(Adapter)的定义如下:将一个接口转换为使用者希望得到的另外一个接口,使得原来不能适配的不能一起工作的
类能够一起工作。
适配器模式分为类结构型模式和对象结构型模式两种,前者类之间的耦合度比后者高,使用继承或者实现的方式,后者使用关联的方式解耦。
另外还有一种是缺省适配器模式(Default Adapter Pattern),当无需实现一个接口的所有方法时,可能通过抽象类实现空方法的方式,让具体实现的子类去覆盖抽象类中的方法,来实现自定义方法的实现。
缺省适配器模式是适配器模式的一种变体,其应用也较为广泛。在JDK类库的事件处理包java.awt.event中广泛使用了缺省适配器模式,如WindowAdapter、KeyAdapter、MouseAdapter等。
模式的结构与实现
适配器模式的结构在Java中可以定义一个适配器来实现当前系统的接口,同时又继承现有组件库中的组件。在适配器中完成现有组件和目标接口的适配。
1.适配器模式结构对象
- 目标(Target)接口:当前系统所需要的接口,可以是抽象类或者接口
- 适配者(Adaptee)类:已有组件或者接口,被适配者角色
- 适配器类(adapter)类:它是一个转换器,通过继承或引用适配者的对象,把适配者接口转换成目标接口,让客户按目标接口的格式访问适配者。
适配器模式的结构图如下:
1.类结构模式(继承或者实现方式)
2.对象适配(引用)
3.缺省模式
示例代码:
1.类结构模式(继承或者实现方式)
模拟电源适配,220v标准电压,转手机充电所需5v电压。
- 适配者(标准电压)
1 | java复制代码public class Adaptee { |
- 目标接口
1 | java复制代码public interface Target { |
- 适配器(继承适配者,实现目标接口)
1 | java复制代码public class Adapter extends Adaptee implements Target{ |
- 使用方
1 | java复制代码public class Client { |
执行结果:
1 | java复制代码 被适配标准电压:220V |
类结构模式案例类图:
2.对象适配
- 适配者 (标准电压)
1 | java复制代码public class Adaptee { |
- 目标接口
1 | java复制代码public interface Target { |
- 适配器(引用适配者)
1 | java复制代码public class Adapter implements Target{ |
- client 使用方
1 | java复制代码public class Client { |
执行结果:
1 | java复制代码 被适配标准电压220V |
对象适配案例类图:
3.缺省模式
- 目标接口
1 | java复制代码public interface Target { |
- 适配器(抽象类,模式空实现)
1 | java复制代码public abstract class AbstractAdapter implements Target{ |
- 使用方 client, 子类覆盖需要使用的方法
1 | java复制代码public class Client { |
执行结果:
1 | java复制代码 this method m1 |
缺省模式案例结构图:
适配器模式应用场景
适配器模式(Adapter)通常适用于以下场景。
- 已有老的系统存在满足新系统功能需求的类,但其接口同新系统的接口不一致。
- 使用第三方提供的组件,但组件接口定义和自己要求的接口定义不同。
适配器模式的优缺点
优点如下:
- 客户端通过适配器可以透明地调用目标接口。
- 复用了现存的类,现有系统不需要修改原有代码而重用现有的适配者类。
- 将目标类和适配者类解耦,解决了目标类和适配者类接口不一致的问题。
- 在很多业务场景中符合开闭原则。
其缺点是:
- 适配器编写过程需要结合业务场景全面考虑,可能会增加系统的复杂性。
- 增加代码阅读难度,降低代码可读性,过多使用适配器会使系统代码变得凌乱。
适配器模式在源码中的使用
1.SpringMVC中的适配器
SpringMVC中使用到适配器模式的地方,是我们的调用核心派发类DispatcherServlet
中的doDispatch()
方法;不妨先看下SpringMVC一个请求进来的数据流转流程:
这张图的流程,应该不用详细赘述,SpringMVC框架的请求处理流程就是图示中所显示。
回到这篇文章的主题,适配器模式是如何运用到这个流程中的,这里先看下HandlerMapping
这里的HandlerMapping
可以简单理解为的Controller
,他是通过请求的Url来映射具体的Controller
,不同的Cotroller
实现方式的不同,对应的Controller
处理类也不同,常用的例如@controller
注解的方式,或者实现Controller
的方式;而HandlerAdapter
是如何通过Hander
知道我们调用的是哪个处理器。
首先看下HandlerAdapter
接口
1 | java复制代码public interface HandlerAdapter { |
他的实现类及子类的结构图:
这里不同实现的适配器,就决定我们前面说的适配不同方式实现的Controller
,拿常用的注解方式来说,对应的适配器为RequestMappingHandlerAdapter
,继承抽象的AbstractHandlerMethodAdapter
,HandlerAdapter
接口中,两个方法比较重要supports(object o)
,判断适配器是否满足当前请求,handle(HttpServletRequest var1, HttpServletResponse var2, Object var3)
,调用Controller
方法,返回ModelAndView
对象。
具体的结构类图:
回到主干看下DispatcherServlet
类的doDispatch()
方法。篇幅限制,删减部分代码
1 | java复制代码try { |
getHandlerAdapter()获取适配器
1 | java复制代码protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException { |
从源码中可以看到,获取适配器的过程就是通过遍历系统中所有适配器,通过supports
,方法找到指定的适配器。而这个适配器是何时注册进去的。
可以发现handlerAdapters其实就是List集合。通过初始化方法注册
1 | java复制代码 /** List of HandlerAdapters used by this servlet. */ |
initHandlerAdapters(context)从容器中获取适配器中对象。
通过源码分析SpringMVC中适配器的使用,HandlerAdapter
接口为我们的目标接口,不同的实现类为具体的适配器角色,而不同请求类型的Controller
为具体的适配者角色,这里宽泛的认为HandlerMapping
为Controller
角色,当然Controller
到HandlerMapping
子类的实现,如何通过注解或者继承的方式来实现这里不做叙述,具体细节查看源码。
本文转载自: 掘金