（6）Java设计模式 - 适配器模式（Adapter Pattern）

逃离我推掉我的手 2022-07-28 09:42 121阅读 0赞

## 介绍 ##

我们接着讨论设计模式，上篇文章我讲完了5种创建型模式，这章开始，我将讲下7种结构型模式：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。其中对象的适配器模式是各种模式的起源，我们看下面的图：

![e28698b9-994e-3fa8-8810-16f30e7cf3e3.jpg][]

适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。

著名的设计模式“四人帮”这样评价适配器模式： 将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。——Gang of Four

适配器模式将一个类的接口适配成用户所期待的。一个适配器通常允许因为接口不兼容而不能一起工作的类能够在一起工作，做法是将类自己的接口包裹在一个已存在的类中。

Adapter 设计模式主要目的组合两个不相干类，常用有两种方法，第一种解决方案是修改各自类的接口。但是如果没有源码，或者不愿意为了一个应用而修改各自的接口，则需要使用 Adapter 适配器，在两种接口之间创建一个混合接口。

## 类适配器模式 ##

类的适配器模式把适配的类的API转换成为目标类的API。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BhbmdlMTk5MQ_size_16_color_FFFFFF_t_70][]

在上图中可以看出，Adaptee类并没有sampleOperation2()方法，而客户端则期待这个方法。为使客户端能够使用Adaptee类，提供一个中间环节，即类Adapter，把Adaptee的API与Target类的API衔接起来。Adapter与Adaptee是继承关系。

主要角色：

*  **Target（目标）：**这就是所期待得到的接口。注意：由于这里讨论的是类适配器模式，因此目标不可以是类。
 *  **Adaptee(源，即被适配者)：**现在需要适配的接口。
 *  **Adaper（适配器）：**适配器类是本模式的核心。适配器把源接口转换成目标接口。显然，这一角色不可以是接口，而必须是具体类。

### 源代码 ###

public interface Target {
        /**
         * 这是源类Adaptee也有的方法
         */
        void sampleOperation1(); 
        /**
         * 这是源类Adapteee没有的方法
         */
        void sampleOperation2(); 
    }

上面给出的是目标角色的源代码，这个角色是以一个JAVA接口的形式实现的。可以看出，这个接口声明了两个方法：sampleOperation1()和sampleOperation2()。而源角色Adaptee是一个具体类，它有一个sampleOperation1()方法，但是没有sampleOperation2()方法。

public class Adaptee {
        
        public void sampleOperation1(){}
    
    }

适配器角色Adapter扩展了Adaptee,同时又实现了目标(Target)接口。由于Adaptee没有提供sampleOperation2()方法，而目标接口又要求这个方法，因此适配器角色Adapter实现了这个方法。

public class Adapter extends Adaptee implements Target {
        /**
         * 由于源类Adaptee没有方法sampleOperation2()
         * 因此适配器补充上这个方法
         */
        @Override
        public void sampleOperation2() {
            //写相关的代码
        }
    
    }

测试类

public class Client {
        public static void main(String[] args) {
            Target target = new Adapter();
            target.sampleOperation2();
        }
    }

##  对象适配器模式 ##

与类的适配器模式一样，对象的适配器模式把被适配的类的API转换成为目标类的API，与类的适配器模式不同的是，对象的适配器模式不是使用继承关系连接到Adaptee类，而是使用委派关系连接到Adaptee类。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BhbmdlMTk5MQ_size_16_color_FFFFFF_t_70 1][]

从上图可以看出，Adaptee类并没有sampleOperation2()方法，而客户端则期待这个方法。为使客户端能够使用Adaptee类，需要提供一个包装(Wrapper)类Adapter。这个包装类包装了一个Adaptee的实例，从而此包装类能够把Adaptee的API与Target类的API衔接起来。Adapter与Adaptee是委派关系，这决定了适配器模式是对象的。

### 源代码 ###

public class Adaptee {
    
        public void sampleOperation1(){}
        
    }

public class Adapter {
        private Adaptee adaptee;
        
        public Adapter(Adaptee adaptee){
            this.adaptee = adaptee;
        }
        /**
         * 源类Adaptee有方法sampleOperation1
         * 因此适配器类直接委派即可
         */
        public void sampleOperation1(){
            this.adaptee.sampleOperation1();
        }
        /**
         * 源类Adaptee没有方法sampleOperation2
         * 因此由适配器类需要补充此方法
         */
        public void sampleOperation2(){
            //写相关的代码
        }
    }

测试类

public class Client {
        public static void main(String[] args) {
            Adaptee adaptee = new Adaptee();
            Target target = new Adapter(adaptee);
            target.sampleOperation2();
        }
    }

第三种适配器模式是**接口的适配器模式**，接口的适配器是这样的：有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，必须实现该接口的所有方法，这明显有时比较浪费，因为并不是所有的方法都是我们需要的，有时只需要某一些，此处为了解决这个问题，我们引入了接口的适配器模式，借助于一个抽象类，该抽象类实现了该接口，实现了所有的方法，而我们不和原始的接口打交道，只和该抽象类取得联系，所以我们写一个类，继承该抽象类，重写我们需要的方法就行。看一下类图：

![a604fca8-e0c6-3e4e-b00a-49da21595b4e.jpg][]

这个很好理解，在实际开发中，我们也常会遇到这种接口中定义了太多的方法，以致于有时我们在一些实现类中并不是都需要。看代码：

public interface Sourceable {  
          
        public void method1();  
        public void method2();  
    }

抽象类Wrapper2：

public abstract class Wrapper2 implements Sourceable{  
          
        public void method1(){}  
        public void method2(){}  
    }

public class SourceSub1 extends Wrapper2 {  
        public void method1(){  
            System.out.println("the sourceable interface's first Sub1!");  
        }  
    }

public class SourceSub2 extends Wrapper2 {  
        public void method2(){  
            System.out.println("the sourceable interface's second Sub2!");  
        }  
    }

public class WrapperTest {  
      
        public static void main(String[] args) {  
            Sourceable source1 = new SourceSub1();  
            Sourceable source2 = new SourceSub2();  
              
            source1.method1();  
            source1.method2();  
            source2.method1();  
            source2.method2();  
        }  
    }

测试输出：

the sourceable interface's first Sub1!  
the sourceable interface's second Sub2!

达到了我们的效果！

讲了这么多，总结一下三种适配器模式的应用场景：

类的适配器模式：当希望将**一个类**转换成满足**另一个新接口**的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。

对象的适配器模式：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个包装(Wrapper)类Adapter，持有原类的一个实例，在Adapter类的方法中，调用实例的方法就行。

接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。

以下情况比较适合使用 Adapter 模式：

1.  当你想使用一个已经存在的类，而它的接口不符合你的需求；
2.  你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作；
3.  你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口，对象适配器可以适配它的父亲接口。

## 优缺点 ##

**优点：**

1.  可以让任何两个没有关联的类一起运行。
2.  提高了类的复用。
3.  增加了类的透明度。
4.  灵活性好。

**缺点：**

1.  过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
2.  由于 Java 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。

## 实际应用的例子 ##

**JDK中体现：**  
（1）java.io.InputStreamReader（该类继承了Read类，但要创建它的对象必须在构造函数中传入一个InputStream）(InputStream→Reader 字节到字符)  
（2）java.io.OutputStreamWriter(OutputStream)  
类图：  
![0_1294058999cvJS.gif][]

[适配器模式及其在springmvc中的应用][springmvc]

适配器模式在开源项目中的应用

[e28698b9-994e-3fa8-8810-16f30e7cf3e3.jpg]: /images/20220724/3786209fe0504f129e1b0883ee43f979.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BhbmdlMTk5MQ_size_16_color_FFFFFF_t_70]: /images/20220724/9b65e4b484b54df8b72465e8ca047501.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BhbmdlMTk5MQ_size_16_color_FFFFFF_t_70 1]: /images/20220724/43936a55397742bd9375603be8293853.png
[a604fca8-e0c6-3e4e-b00a-49da21595b4e.jpg]: /images/20220724/a9b4224bcf5b4a8e83c9ea8c6054f697.png
[0_1294058999cvJS.gif]: /images/20220724/8f910e8babd545388d62f1902cecc72e.png
[springmvc]: http://shaw-n-lu.iteye.com/blog/1927150