适配器模式 ( Adapter Pattern ) 可以将接口转换成期望的另一个接口，使得那些接口不兼容的类可以一起工作，别名又为包装器 ( Wrapper )。
Spring AOP 中的适配器模式
Spring AOP 的实现是基于代理模式的，但是 Spring AOP 的增强和通知 ( Advice ) 使用到了适配器模式，与之相关的接口是 AdvisorAdapter 。
Advice 常用的类型有：
-
BeforeAdvice（目标方法调用前,前置通知） -
AfterAdvice（目标方法调用后，后置通知） -
AfterReturningAdvice( 目标方法执行结束后，return 之前 ) 等等。
每个类型 Advice（通知）都有对应的拦截器：
MethodBeforeAdviceInterceptorAfterReturningAdviceAdapterAfterReturningAdviceInterceptor
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 类型，就要在上面代码中再加入一行判断语句，这种形式就使得程序难以维护，也违反了设计模式中的 开闭原则 – 对扩展开放，对修改关闭。
