设计模式——适配器模式（Adapter）

布满荆棘的人生 2022-08-11 00:43 196阅读 0赞

# 要想正确理解设计模式，首先必须明确它是为了解决什么问题而提出来的。  设计模式学习笔记  ——Shulin  转载请注明出处：[http://blog.csdn.net/zhshulin][http_blog.csdn.net_zhshulin]      #

# 基本概念 #

适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

在GoF的设计模式中，对适配器模式讲了两种类型，类适配器模式和对象适配器模式。适配器模式还有一个特例，就是缺省适配模式（Default Adapter），又称接口适配模式。

1、 类适配器模式

把适配类的API转换成目标类的API， 由于类适配器模式通过多重继承对一个接口与另一个接口进行匹配，虽然C\#、java等 语言都不支持多重继承，但是也可以简单的使用类           的适配器模式。

2、 对象适配器模式

与类的适配器模式一样，不同之处在于，对象的适配器模式不是使用继承关系连接到Adaptee类，而是使用关联关系连接到Adaptee类。

3、缺省适配器模式，又称接口适配器模式

缺省适配模式为一个接口提供缺省实现，这样子类型可以从这个缺省实现进行扩展，而不必从原有接口进行扩展。作为适配器模式的一个特例，缺省是适配模式在JAVA语言     中有着特殊的应用。

# 针对的问题 #

使原本因为接口不兼容而无法在一起动作的类可以在一起工作。

# 类适配器模式 #

我们通过一个例子来学习类的适配器模式：日常生活中，笔记本电脑的插头一般都是三相的，即除了阳极、阴极外，还有一个地极。而有些地方的电源插座却只有两极，没有地极。电源插座与笔记本电脑的电源插头不匹配使得笔记本电脑无法使用。这时候一个三相到两相的转换器（适配器）就能解决此问题，而这正像是本模式所做的事情。

## 类图： ##

![Center][]

## 源代码 ##

核心思想：有一个Adaptee类，拥有一个方法getReceptacle1()，待适配，目标接口Target，通过Adapter类，将Adaptee的功能扩展到Target里面，看代码：

Adaptee类，待适配的类

public class Adaptee {
    	/**
    	 * 取得插座
    	 */
    	public void getReceptacle1(){
    		System.out.println("这是一个两孔插座！");
    	}
    }

Target类，目标接口

public interface Target {
    	/**
    	 * 取得两孔插座
    	 */
    	public void getReceptacle1();
    	/**
    	 * 取得三孔插座
    	 */
    	public void getReceptacle2();
    }

Adapter类

/**
     * 此类目标是让电脑可以使用2空插座，解决了接口不匹配问题，同时扩展了功能。
     * @author ZSL
     */
    public class Adapter extends Adaptee implements Target {
    
    	@Override
    	public void getReceptacle2() {
    		System.out.println("扩展插口，此为三孔插口！");
    	}
    
    }

测试类：

/**
     * 测试类
     * @author ZSL
     */
    public class Computer {
    	public static void main(String[] args) {
    		Target target = new Adapter();
    		target.getReceptacle1();
    		target.getReceptacle2();	//这个功能就是适配器扩展的功能
    	}
    }

# 对象适配器模式 #

与类的适配器模式一样，不同之处在于，对象的适配器模式不使用继承关系连接到Adaptee类，而是使用关联关系连接到Adaptee类。类图如下：

![Center 1][]

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

## 源代码 ##

与类适配器模式相比，除了适配器类需要修改一下，其他一样。

Adapter类

/**
     * 对象适配器模式，
     * @author Administrator
     *
     */
    public class Adapter2 implements Target {
    	private Adaptee adaptee;
    	
    	public Adapter2(Adaptee adaptee){
    		this.adaptee = adaptee;
    	}
    	/**
    	 * 待适配的类有次方法，适配器直接使用即可
    	 */
    	@Override
    	public void getReceptacle1() {
    		this.adaptee.getReceptacle1();
    	}
    	/**
    	 * 代适配的类无此方法，适配器补充
    	 */
    	@Override
    	public void getReceptacle2() {
    		System.out.println("扩展插口，此为三孔插口！");
    	}
    
    }

测试类：

/**
     * 测试类
     * @author ZSL
     */
    public class Computer {
    	public static void main(String[] args) {
    		Adaptee adaptee = new Adaptee();
    		Target target = new Adapter2(adaptee);
    		target.getReceptacle1();
    		target.getReceptacle2();	//这个功能就是适配器扩展的功能
    	}
    }

# 接口适配器模式 #

又称缺省适配(Default Adapter)模式为一个接口提供缺省实现，这样子类型可以从这个缺省实现进行扩展，而不必从原有接口进行扩展。作为适配器模式的一个特例，缺省是适配模式在JAVA语言中有着特殊的应用。

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

引用一个例子说明（鲁智深的故事）：（例子来源：http://www.cnblogs.com/java-my-life/archive/2012/04/13/2442795.html）

和尚要做什么呢？吃斋、念经、打坐、撞钟、习武等。如果设计一个和尚接口，给出所有的和尚都需要实现的方法，那么这个接口应当如下：

public interface 和尚 {
        public void 吃斋（）；
        public void 念经（）；
        public void 打坐（）；
        public void 撞钟（）；
        public void 习武（）；
        public String getName();
    }

显然，所有的和尚类都应当实现接口所定义的全部方法，不然就根本通不过JAVA语言编辑器。像下面的鲁智深类就不行。

public class 鲁智深 implements 和尚{
        public void 习武(){
            拳打镇关西；
            大闹五台山；
            大闹桃花村；
            火烧瓦官寺；
            倒拔垂杨柳；
        }
        public String getName(){
            return "鲁智深";
        }
    }

由于鲁智深只实现了getName()和习武()方法，而没有实现任何其他的方法。因此，它根本就通不过Java语言编译器。鲁智深类只有实现和尚接口的所有的方法才可以通过Java语言编译器，但是这样一来鲁智深就不再是鲁智深了。以史为鉴，可以知天下。研究一下几百年前鲁智深是怎么剃度成和尚的，会对Java编程有很大的启发。不错，当初鲁达剃度，众僧说：“此人形容丑恶、相貌凶顽，不可剃度他",但是长老却说：”此人上应天星、心地刚直。虽然时下凶顽，命中驳杂，久后却得清净。证果非凡，汝等皆不及他。”

原来如此！看来只要这里也应上一个天星的话，问题就解决了！使用面向对象的语言来说，“应”者，实现也；“天星”者，抽象类也。

public abstract class 天星 implements 和尚 {
        public void 吃斋(){}
        public void 念经(){}
        public void 打坐(){}
        public void 撞钟(){}
        public void 习武(){}
        public String getName(){
            return null;
        }
    }

鲁智深类继承抽象类“天星”

public class 鲁智深 extends 天星{
        public void 习武(){
            拳打镇关西；
            大闹五台山；
            大闹桃花村；
            火烧瓦官寺；
            倒拔垂杨柳；
        }
        public String getName(){
            return "鲁智深";
        }
    }

这个抽象的天星类便是一个适配器类，鲁智深实际上借助于适配器模式达到了剃度的目的。此适配器类实现了和尚接口所要求的所有方法。但是与通常的适配器模式不同的是，此适配器类给出的所有的方法的实现都是“平庸”的。这种“平庸化”的适配器模式称作缺省适配模式。

在很多情况下，必须让一个具体类实现某一个接口，但是这个类又用不到接口所规定的所有的方法。通常的处理方法是，这个具体类要实现所有的方法，那些有用的方法要有实现，那些没有用的方法也要有空的、平庸的实现。

这些空的方法是一种浪费，有时也是一种混乱。除非看过这些空方法的代码，程序员可能会以为这些方法不是空的。即便他知道其中有一些方法是空的，也不一定知道哪些方法是空的，哪些方法不是空的，除非看过这些方法的源代码或是文档。

缺省适配模式可以很好的处理这一情况。可以设计一个抽象的适配器类实现接口，此抽象类要给接口所要求的每一种方法都提供一个空的方法。就像帮助了鲁智深的“上应天星”一样，此抽象类可以使它的具体子类免于被迫实现空的方法。

# 类适配器和对象适配器比较 #

<table> 
 <tbody> 
 <tr> 
 <td>类适配器</td> 
 <td>对象适配器</td> 
 </tr> 
 <tr> 
 <td>使用对象继承的方式，是静态的定义方式</td> 
 <td>使用对象组合的方式，是动态组合的方式</td> 
 </tr> 
 <tr> 
 <td>适配器可以重定义Adaptee的部分行为，相当于子类覆盖父类的部分实现</td> 
 <td>要重定义Adaptee的行为比较困难，这种情况下，需要定义Adaptee的子类来实现重定义，然后让适配器组合子类。虽然重定义Adaptee的行为比较困难，但是想要增加一些新的行为则方便的很，而且新增加的行为可同时适用于所有的源。</td> 
 </tr> 
 <tr> 
 <td>仅仅引入了一个对象，并不需要额外的引用来间接得到Adaptee</td> 
 <td>需要额外的引用来间接得到Adaptee</td> 
 </tr> 
 </tbody> 
</table>

# 适配器优点 #

1、 更好的复用性

系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。

2、 更好的扩展性

在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。

# 适配器缺点 #

过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。

（原文地址：http://blog.csdn.net/zhshulin）

[http_blog.csdn.net_zhshulin]: http://blog.csdn.net/zhshulin
[Center]: /images/20220810/d1db4dc378fa49feb7b19128ec17ad25.png
[Center 1]: /images/20220810/0b380352bcc14454a5bb8637c92365c7.png