适配器模式 ( Adapter Pattern ) 可以将接口转换成期望的另一个接口,使得那些接口不兼容的类可以一起工作,别名又为包装器 ( Wrapper )。
Spring AOP 中的适配器模式
Spring AOP 的实现是基于代理模式的,但是 Spring AOP 的增强和通知 ( Advice ) 使用到了适配器模式,与之相关的接口是 AdvisorAdapter
。
Advice 常用的类型有:
-
BeforeAdvice
(目标方法调用前,前置通知) -
AfterAdvice
(目标方法调用后,后置通知) -
AfterReturningAdvice
( 目标方法执行结束后,return 之前 ) 等等。
每个类型 Advice(通知)都有对应的拦截器:
MethodBeforeAdviceInterceptor
AfterReturningAdviceAdapter
AfterReturningAdviceInterceptor
Spring 预定义的通知要通过对应的适配器,适配成 MethodInterceptor
接口 ( 方法拦截器 ) 类型的对象(如:MethodBeforeAdviceInterceptor
负责适配 MethodBeforeAdvice
)。
Spring MVC 中的适配器模式
在 Spring MVC 中,DispatcherServlet
根据请求信息调用 HandlerMapping
,解析请求到对应的 Handler
(也就是平常说的 Controller
控制器)后,开始由 HandlerAdapter
适配器进行处理。HandlerAdapter
作为期望接口,具体的适配器实现类用于对目标类进行适配,而 Controller
就作为需要适配的类。
为什么要在 Spring MVC 中使用适配器模式?
Spring MVC 中的 Controller
种类众多,不同类型的 Controller
,通过不同的方法来对请求进行处理。如果不利用适配器设计模式的话,而让 DispatcherServlet
直接获取对应类型的 Controller
,还需要自行来进行判断,像下面这段代码一样:
if(mappedHandler.getHandler() instanceof MultiActionController){
((MultiActionController)mappedHandler.getHandler()).xxx
}else if(mappedHandler.getHandler() instanceof XXX){
...
}else if(...){
...
}
假如再增加一个 Controller
类型,就要在上面代码中再加入一行判断语句,这种形式就使得程序难以维护,也违反了设计模式中的 开闭原则 – 对扩展开放,对修改关闭。