适配器模式的定义

将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。(就类似于我们充电器的转接头将220V的电压转换成我们的手机端可以接收的电压3.5-4.2之间)

曾经有一个面试题：问I/O流中的InputStreamReader用到的是什么设计模式思想？用的就是我们的Adapter模式，将字节流转换成字符流的桥梁。

适配器模式的参与者

    1.Target

      定义Client使用的与特定领域相关的接口。

    2.Client

      与符合Target接口的对象协同。

    3.Adaptee

      定义一个已经存在的接口，这个接口需要适配。

    4.Adapter

      对Adaptee的接口与Target接口进行适配

适配器模式的UML类图

　　　　　　　　　                                　　　

我们用代码来实现一下(以下内容参考：http://haolloyin.blog.51cto.com/1177454/346128,这种设计模式比较简单，就直接把别人的代码拿过来了)

第一步：定义Adaptee,已存在的、具有特殊功能、但不符合我们既有的标准接口的类

public class Adaptee {

    public void specialRequest(){
        System.out.println("被适配，具有特殊功能");
    }
}

第二步：定义Target,目标接口，或称为标准接口

1 public interface Target {
2     public void request();
3 }

第三步：定义ConcreteTarget，具体目标类，只提供普通功能

1 public class ConcreteTarget implements Target{
2 
3     @Override
4     public void request() {
5         System.out.println("普通类，具有普通功能");
6     }
7 }

第四步：定义Adapter,适配器类，继承了被适配类，同时实现标准接口

1 public class Adapter extends Adaptee implements Target {
2 
3     public void request(){
4         super.specialRequest();
5     }
6 }

第五步：定义Client,我们的客户端测试代码

 1 //测试类
 2 public class Client {
 3     public static void main(String[] args) {
 4         // 使用普通功能类
 5         Target concreteTarget = new ConcreteTarget();
 6         concreteTarget.request();
 7         
 8         // 使用特殊功能类，即适配类
 9         Target adapter = new Adapter();
10         adapter.request();
11     }
12 }

测试结果：

普通类，具有普通功能
被适配，具有特殊功能

上面这种实现的适配器称为类适配器，因为 Adapter 类既继承了 Adaptee （被适配类），也实现了 Target 接口（因为 Java 不支持多继承，所以这样来实现），在 Client 类中我们可以根据需要选择并创建任一种符合需求的子类，来实现具体功能。

另外一种适配器模式是对象适配器，它不是使用多继承或继承再实现的方式，而是使用直接关联，或者称为委托的方式，类图如下：

　　　　　　　　　　　　　　　　　　

则第四步的Adapter可以这样写：

 1 // 适配器类，直接关联被适配类，同时实现标准接口
 2 class Adapter implements Target{
 3     // 直接关联被适配类
 4     private Adaptee adaptee;
 5     
 6     // 可以通过构造函数传入具体需要适配的被适配类对象
 7     public Adapter (Adaptee adaptee) {
 8         this.adaptee = adaptee;
 9     }
10     
11     public void request() {
12         // 这里是使用委托的方式完成特殊功能
13         this.adaptee.specificRequest();
14     }
15 }

测试类：

 1 // 测试类
 2 public class Client {
 3     public static void main(String[] args) {
 4         // 使用普通功能类
 5         Target concreteTarget = new ConcreteTarget();
 6         concreteTarget.request();
 7         
 8         // 使用特殊功能类，即适配类，
 9         // 需要先创建一个被适配类的对象作为参数
10         Target adapter = new Adapter(new Adaptee());
11         adapter.request();
12     }
13 }

博客原文给出的总结(直接粘贴过来了....他说的有些内容我还没看到，继续学习吧！)
测试结果与上面的一致。从类图中我们也知道需要修改的只不过就是 Adapter 类的内部结构，即 Adapter 自身必须先拥有一个被适配类的对象，再把具体的特殊功能委托给这个对象来实现。使用对象适配器模式，可以使得 Adapter 类（适配类）根据传入的 Adaptee 对象达到适配多个不同被适配类的功能，当然，此时我们可以为多个被适配类提取出一个接口或抽象类。这样看起来的话，似乎对象适配器模式更加灵活一点。

小结：

1、适配器模式也是一种包装模式，与之前的 Decorator 装饰模式同样具有包装的功能；此外，对象适配器模式还具有显式委托的意思在里面（其实类适配器也有这种意思，只不过比较隐含而已），那么我在认为它与 Proxy 代理模式也有点类似；

2、从上面一点对比来看， Decorator 、 Proxy、 Adapter 在实现了自身的最主要目的（这个得看各个模式的最初动机、描述）之外，都可以在包装的前后进行额外的、特殊的功能上的增减，因为我认为它们都有委托的实现意思在里面；

3、我所看的书中说适配器模式不适合在详细设计阶段使用它，它是一种补偿模式，专用来在系统后期扩展、修改时所用。

转载于:https://www.cnblogs.com/ysw-go/p/5408860.html

原文链接：https://blog.csdn.net/weixin_30342827/article/details/98920427

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理。