适配器模式——得心应手的“粘合剂”
来源:互联网 发布:多文件编程 编辑:程序博客网 时间:2024/04/29 22:21
适配器模式在日常开发中使用率极高,从代码中随处可见的Adapter就可以看出来。在Android中,ListView,GridView到现在最新的RecyclerView都需要使用Adapter,并且在开发中我们遇到的优化问题,出错概率较大的地方也基本来自Adapter,这是一个让人又爱又恨的角色。
言归正传,适配器是将两个不兼容的类融合在一起,它有点像粘合剂,将不同的东西通过一种转换使得它们能够协作起来。例如,经常碰到要在两个没有关系的类型之间进行交互。第一个解决方法时修改各自的接口,但是如果没有源代码要在或者我们不愿意为了一个应用而修改各自的接口,此时我们往往需要使用一个Adapter,在这两种接口之间创建一个接口,这个Adapter会将这两个接口进行兼容,在不修改原有代码的情况下满足需求。
适配器模式把一个类的接口变换陈客户端所期待的另一种接口,从而使原本因接口不匹配而无法再一起工作的两个类能够子啊一起工作。
模式中的角色
目标接口(Target):客户所期待的接口。目标可以是具体的或抽象的类,也可以是接口。
需要适配的类(Adaptee):需要适配的类或适配者类。
适配器(Adapter):通过包装一个需要适配的对象,把原接口转换成目标接口。
实现方式主要有两种:
类的是适配器模式
对象适配器模式
1)类的是适配器模式
UML类图如图所示
类的适配器模式采用继承方式实现
Adaptee.java
package com.test.adapter;public class Adaptee {public void specificRequest() {System.out.println("被适配类...的特异功能");}}Target.java
package com.test.adapter;public interface Target {public void request(); }ConcreteTarget.java
package com.test.adapter;public class ConcreteTarget implements Target{@Overridepublic void request() {// TODO Auto-generated method stub System.out.println("普通类、、、没有特异功能"); }}Adapter.java
package com.test.adapter;public class Adapter extends Adaptee implements Target{@Overridepublic void request() {// TODO Auto-generated method stubsuper.specificRequest(); }}
最后是客户端
Client.java
package com.test.adapter;public class Client {public static void main(String[] args) {// 使用普通功能类Target concreteTarget = new ConcreteTarget();concreteTarget.request();// 使用特殊功能类,即适配类Target adapter = new Adapter();adapter.request();}}运行结果如下
普通类、、、没有特异功能被适配类...的特异功能
2)对象适配器模式
UML类图如图所示
与类的适配器模式不同的是,对象的适配器模式不是使用继承关系连接到Adaptee类,而是使用代理关系连接到Adaotee类。
此时只需要修改Adapter.java
public class Adapter implements Target{// 直接关联被适配类 private Adaptee adaptee; // 可以通过构造函数传入具体需要适配的被适配类对象 public Adapter (Adaptee adaptee) { this.adaptee = adaptee; } @Overridepublic void request() {// TODO Auto-generated method stubadaptee.specificRequest();}}
客户端也要稍微修改一下
public class Client {public static void main(String[] args) {// 使用普通功能类Target concreteTarget = new ConcreteTarget();concreteTarget.request();// 使用特殊功能类,即适配类Target adapter = new Adapter(new Adaptee());adapter.request();}}
只是new Adapter(new Adaptee());构造方法传入了新的参数,其它一样的,运行结果也是一样的。
从类图中我们也知道需要修改的只不过就是 Adapter 类的内部结构,即 Adapter 自身必须先拥有一个被适配类的对象,再把具体的特殊功能委托给这个对象来实现。使用对象适配器模式,可以使得 Adapter 类(适配类)根据传入的 Adaptee 对象达到适配多个不同被适配类的功能,当然,此时我们可以为多个被适配类提取出一个接口或抽象类。这样看起来的话,似乎对象适配器模式更加灵活一点。
总结
Adapter模式的经典实现在于将原本不兼容的接口融合在一起,使之能够很好的进行合作,但是在实际开发中,Adapter模式也有灵活的实现,可以稍微修改一下。例如ListView中的BaseAdapter,SimpleAdapter就稍微做了一下修改。
优点:
1)更好的复用性
2)更好的扩展性
缺点:
过多的使用适配器,会让系统凌乱,不易整体把握。
- 适配器模式——得心应手的“粘合剂”
- SWIG——万能粘合剂
- 模式的秘密——适配器模式
- 适配器模式-Adapter Pattern 不兼容结构的协调——适配器模式(四):缺省适配器,适配器模式总结
- 不兼容结构的协调——适配器模式(四):缺省适配器,适配器模式总结
- 适配器模式-Adapter Pattern 不兼容结构的协调——适配器模式(三):类适配器,双向适配器
- Adapter—适配器模式
- Android图表库MPAndroidChart(一)——了解他的本质,方能得心应手
- Android图表库MPAndroidChart(一)——了解他的本质,方能得心应手
- Android图表库MPAndroidChart(一)——了解他的本质,方能得心应手
- 不兼容结构的协调——适配器模式(三):类适配器,双向适配器
- 设计模式—适配器模式
- 设计模式—适配器模式
- 设计模式—适配器模式
- 设计模式—适配器模式
- 设计模式—适配器模式
- 设计模式—适配器模式
- 设计模式—适配器模式
- Spring事务Transaction配置的五种注入方式详解
- 使用Spring MVC的@ControllerAdvice注解做Json的异常处理
- 【步兵 cocos2dx】texturePacker命令行
- 最详细的Log4j使用教程
- Oblique View Frustum
- 适配器模式——得心应手的“粘合剂”
- C++中传值、传址与传引用的区别
- 安天发布《DDOS攻击之鬼影DDOS家族分析》
- MemCache
- Missing assembly: DevExpress.XtraPrinting.v11.2.
- CodeForces 213C Relay Race(dp)
- ST算法学习——POJ3264
- 解决org.apache.ibatis.binding.BindingException: Invalid bound statement (not found):
- quartz基础知识