泰国旅游使用插座问题
现实生活中的适配器例子
泰国插座用的是两孔的(欧标),可以买个多功能转换插头(适配器),这样就可以使用了
基本介绍
- 1)适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示,主的目的是兼容性,让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)
- 2)适配器模式属于结构型模式
- 3)主要分为三类:类适配器模式、对象适配器模式、接口适配器模式
工作原理
- 1)适配器模式:将一个类的接口转换成另一种接口,让原本接口不兼容的类可以兼容
- 2)从用户的角度看不到被适配者,是解耦的
- 3)用户调用适配器转化出来的目标接口方法,适配器再调用被适配者的相关接口方法
- 4)用户收到反馈结果,感觉只是和目标接口交互,如图
类适配器模式
案例
基本介绍:Adapter 类,通过继承 src 类,实现 dst 类接口,完成 src -> dst 的适配
以生活中充电器的例子来讲解适配器,充电器本身相当于 Adapter,220V 交流电相当于 src(即被适配者),我们的 dst(即目标)是 5V 直流电
UML 类图
Adaptee
:适配者类,它是需要被访问的、需要被适配的组件
Target
:目标接口,当前系统业务所使用的接口,可以是抽象类或接口
Adapter
:适配器类,通过继承和实现目标接口,让客户端按照目标接口的方法访问适配者
Client
:客户端,适配器的使用者
核心代码
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
| public class Voltage220V { public Integer output220V() { int src = 220; System.out.println("电压=" + src + "伏"); return src; } }
public interface IVoltage5V { Integer output5V(); }
public class VoltageAdapter extends Voltage220V implements IVoltage5V { @Override public Integer output5V() { int src = output220V(); int dst = src / 44; System.out.println("电压=" + dst + "伏"); return dst; } }
public class Phone { public void charing(IVoltage5V iVoltage5V) { if (iVoltage5V.output5V() == 5) { System.out.println("电压=5伏,正在充电~"); } else { System.out.println("电压!=5伏,无法充电~"); } } }
public class Client { public static void main(String[] args) { Phone phone = new Phone(); phone.charing(new VoltageAdapter()); } }
|
注意事项和细节
- 1)Java 是单继承机制,所以类适配器需要继承 src 类这一点算是一个缺点,因为这要求 dst 必须是接口,有一定局限性
- 2)src 类的方法在 Adapter 中都会暴露出来,也增加了使用的成本
- 3)由于其继承了 src 类,所以它可以根据需求重写 src 类的方法,使得 Adapter 的灵活性增强了
对象适配器模式
- 1)基本思路和类的适配器模式相同,只是将 Adapter 类作修改,不是继承 src 类,而是持有 src 类的实例,以解决兼容性的问题。即:持有 src 类,实现 dst 类接口,完成 src->dst 的适配
- 2)根据“合成复用原则”,在系统中尽量使用关联关系来替代继承关系
- 3)对象适配器模式是适配器模式常用的一种
以生活中充电器的例子来讲解适配器,充电器本身相当于 Adapter,220V 交流电相当于 src(即被适配者),我们的 dst(即目标)是 5V 直流电,使用对象适配器模式完成
UML 类图
核心代码
只需修改 Adapter 类即可
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
| public class VoltageAdapter implements IVoltage5V { private Voltage220V voltage220V;
public VoltageAdapter(Voltage220V voltage220V) { this.voltage220V = voltage220V; }
@Override public Integer output5V() { if (voltage220V == null) { return 0; } int src = voltage220V.output220V(); int dst = src / 44; System.out.println("电压=" + dst + "伏"); return dst; } }
public class Client { public static void main(String[] args) { Phone phone = new Phone(); phone.charing(new VoltageAdapter(new Voltage220V())); } }
|
注意事项和细节
- 1)对象适配器和类适配器其实算是同一种思想,只不过实现方式不同。根据合成复用原则,使用组合替代继承,所以它解决了类适配器必须继承 src 的局限性问题,也不再要求 dst 必须是接口
- 2)使用成本更低,更灵活
接口适配器模式
- 1)一些书籍称为:适配器模式或缺省适配器模式(Default Adapter Pattern)
- 2)当不需要全部实现接口提供的方法时,可先设计一个抽象类实现接口,并为该接口中每个方法提供一个默认实现(空方法),那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求
- 3)适用于一个接口不想使用其所有的方法的情况
实例
1)Android 中的属性动画 ValueAnimator 类可以通过 addListener(AnimatorListener listener)方法添加监听器,那么常规写法如下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
| ValueAnimator valueAnimator = ValueAnimator.ofInt(0, 100); valueAnimator.addListener(new Animator.AnimatorListener() { @Override public void onAnimatorStart(Animator animation) { }
@Override public void onAnimatorEnd(Animator animation) { }
@Override public void onAnimatorCancel(Animator animation) { }
@Override public void onAnimatorRepeat(Animator animation) { } }); valueAnimator.start();
|
2)有时候我们不想实现 Animator.AnimatorListener 接口的全部方法,我们只想监听 onAnimationStart,写法如下
1 2 3 4 5 6 7 8
| ValueAnimator valueAnimator = ValueAnimator.ofInt(0, 100); valueAnimator.addListener(new AnimatorListenerAdapter() { @Override public void onAnimatorStart(Animator animation) { } }); valueAnimator.start();
|
3)AnimatorListenerAdapter 类就是一个接口适配器,它空实现了 Animator.AnimatorListener 类(src)的所有方法
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
| public abstract class AnimatorListenerAdapter implements Animator.AnimatorListener, Animator.AnimatorPauseListener { @Override public void onAnimationCancel(Animator animation) { }
@Override public void onAnimationEnd(Animator animation) { }
@Override public void onAnimationRepeat(Animator animation) { }
@Override public void onAnimationStart(Animator animation) { }
@Override public void onAnimationPause(Animator animation) { }
@Override public void onAnimationResume(Animator animation) { } }
|
4)AnimatorListener 是一个接口
1 2 3 4 5 6 7 8 9
| public static interface AnimatorListener { void onAnimationStart(Animator animation);
void onAnimationEnd(Animator animation);
void onAnimationCancel(Animator animation);
void onAnimationRepeat(Animator animation); }
|
5)程序里的匿名内部类就是 Listener 具体实现类
1 2 3 4 5 6
| new AnimatorListenerAdapter() { @Override public void onAnimationStart(Animator animation){ } }
|
现在我们按照上述步骤,自己去实现一下
UML 类图
核心代码
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
| public interface Interface4 { void operation1();
void operation2();
void operation3();
void operation4(); }
public abstract class AbsAdapter implements Interface4 { @Override public void operation1() { }
@Override public void operation2() { }
@Override public void operation3() { }
@Override public void operation4() { } }
public class Client { public static void main(String[] args) { AbsAdapter absAdapter = new AbsAdapter() { @Override public void operation1() { System.out.println("调用operation1方法"); } }; absAdapter.operation1(); } }
|
SpringMVC 框架源码分析
1)SpringMVC 中的 HandlerAdapter,就使用了适配器模式
2)SpringMVC 处理请求的流程回顾
3)使用 HandlerAdapter 的原因分析
在 DispatcherServlet 中,有一个 doDispatch 方法,其中便使用到了 HandlerAdapter 适配器
通过 request 可以获得一个 Handler,再根据这个 Handler 获得不同的 HandlerAdapter 进行处理
HandlerAdapter 本质上是一个适配器接口,具体的适配器实现类有多种,其中有我们较为熟悉的 HttpRequestHandlerAdapter 和 RequestMappingHandlerAdapter
HandlerAdapter 的实现子类是的每一种 Controller 有一种对应的适配器实现类,每种 Controller 有不同的实现方式
言归正传,拿到 HandlerAdapter 适配器之后,便会调用其中的 handle 方法, 此方法便是具体的适配器实现类需要实现的方法
可以看到处理器的类型不同,有多重实现方式,那么调用方式就不是确定的。如果需要直接调用 Controller 方法,需要调用的时候就得不断使用if-else
来进行判断是哪一种子类然后执行。那么如果后面要扩展 Controller,就得修改原来的代码,这样违背了 OCP 原则
4)为了更深刻地理解其中运用的模式思想,我们自己动手写 SpringMVC,通过适配器设计模式获取到对应的 Controller 的源码
自己动手写 SpringMVC
UML 类图
核心代码
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94
| public interface Controller { }
public class AnnotationController implements Controller { public void doAnnotationHandler() { System.out.println("annotation..."); } }
public class HttpController implements Controller { public void doHttpHandler() { System.out.println("http..."); } }
public class SimpleController implements Controller { public void doSimplerHandler() { System.out.println("simple..."); } }
public interface HandlerAdapter { boolean supports(Object handler);
void handle(Object handler); }
public class AnnotationHandlerAdapter implements HandlerAdapter { @Override public void handle(Object handler) { ((AnnotationController) handler).doAnnotationHandler(); }
@Override public boolean supports(Object handler) { return (handler instanceof AnnotationController); } }
public class HttpHandlerAdapter implements HandlerAdapter { @Override public void handle(Object handler) { ((HttpController) handler).doHttpHandler(); }
@Override public boolean supports(Object handler) { return (handler instanceof HttpController); } }
public class SimpleHandlerAdapter implements HandlerAdapter { @Override public void handle(Object handler) { ((SimpleController) handler).doSimplerHandler(); }
@Override public boolean supports(Object handler) { return (handler instanceof SimpleController); } }
public class DispatchServlet { public static List<HandlerAdapter> handlerAdapters = new ArrayList<>();
public DispatchServlet() { handlerAdapters.add(new AnnotationHandlerAdapter()); handlerAdapters.add(new HttpHandlerAdapter()); handlerAdapters.add(new SimpleHandlerAdapter()); }
public void doDispatch() { SimpleController controller = new SimpleController(); HandlerAdapter adapter = getHandler(controller); adapter.handle(controller); }
public HandlerAdapter getHandler(Controller controller) { for (HandlerAdapter adapter : this.handlerAdapters) { if (adapter.supports(controller)) { return adapter; } } return null; } }
|
说明
- Spring 定义了一个适配接口,使得每一种 Controller 有一种对应的适配器实现类
- 适配器代替 Controller 执行相应的方法
- 扩展 Controller 时,只需要增加一个适配器类就完成了 SpringMVC 的扩展了
- 这就是设计模式的力量
注意事项和细节
1)三种命名方式,是根据 src 是以怎样的形式给到 Adapter(在Adapter里的形式)来命名的
2)三种适配器模式
- 类适配器:以类给到,在 Adapter 里将 src 作为一个类,继承
- 对象适配器:以对象给到,在Adapter 里将 src 作为一个对象,持有
- 接口适配器:以接口给到,在 Adapter 里将 src 作为一个接口,实现
3)Adapter 模式最大的作用还是将原本不兼容的接口融合在一起工作
4)实际开发中,实现起来不拘泥于我们讲解的三种经典形式