适配器模式-Adapter Pattern

适配器模式-Adapter Pattern

适配器模式(Adapter Pattern)：将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。

对象适配器模式结构如图所示：

在对象适配器模式结构图中包含如下几个角色：
● Target（目标抽象类）：目标抽象类定义客户所需接口，可以是一个抽象类或接口，也可以是具体类。

● Adapter（适配器类）：适配器可以调用另一个接口，作为一个转换器，对Adaptee和Target进行适配，适配器类是适配器模式的核心，在对象适配器中，它通过继承Target并关联一个Adaptee对象使二者产生联系。

● Adaptee（适配者类）：适配者即被适配的角色，它定义了一个已经存在的接口，这个接口需要适配，适配者类一般是一个具体类，包含了客户希望使用的业务方法，在某些情况下可能没有适配者类的源代码。

举个栗子：

公司在很久以前曾开发了一个算法库，里面包含了一些常用的算法，例如排序算法和查找算法，在进行各类软件开发时经常需要重用该算法库中的算法。在为某学校开发教务管理系统时，开发人员发现需要对学生成绩进行排序和查找，该系统的设计人员已经开发了一个成绩操作接口ScoreOperation，在该接口中声明了排序方法sort(int[]) 和查找方法search(int[], int)，为了提高排序和查找的效率，开发人员决定重用算法库中的快速排序算法类QuickSort和二分查找算法类BinarySearch，其中QuickSort的quickSort(int[])方法实现了快速排序，BinarySearch 的binarySearch (int[], int)方法实现了二分查找。

由于某些原因，现在Sunny公司开发人员已经找不到该算法库的源代码，无法直接通过复制和粘贴操作来重用其中的代码；部分开发人员已经针对ScoreOperation接口编程，如果再要求对该接口进行修改或要求大家直接使用QuickSort类和BinarySearch类将导致大量代码需要修改。

根据对象适配器模式结构图，在对象适配器中，客户端需要调用request()方法，而适配者类
Adaptee没有该方法，但是它所提供的specificRequest()方法却是客户端所需要的。为了使客户端能够使用适配者类，需要提供一个包装类Adapter，即适配器类。这个包装类包装了一个适配者的实例，从而将客户端与适配者衔接起来，在适配器的request()方法中调用适配者的
specificRequest()方法。因为适配器类与适配者类是关联关系（也可称之为委派关系），所以这种适配器模式称为对象适配器模式。典型的对象适配器代码如下所示：

class Adapter extends Target {
   private Adaptee adaptee; //维持一个对适配者对象的引用
  
   public Adapter(Adaptee adaptee) {
   this.adaptee=adaptee;
  }
  
   public void request() {
   adaptee.specificRequest(); //转发调用
    }
    }

公司开发人员决定使用适配器模式来重用算法库中的算法，其基本结构如图所示：

在图中，ScoreOperation接口充当抽象目标，QuickSort和BinarySearch类充当适配者，OperationAdapter充当适配器。完整代码如下所示：

//抽象成绩操作类：目标接口
   interface ScoreOperation {
   public int[] sort(int array[]); //成绩排序
   public int search(int array[],int key); //成绩查找
   }
  
   //快速排序类：适配者
   class QuickSort {
   public int[] quickSort(int array[]) {
    sort(array,0,array.length-1);
    return array;
    }
   
    public void sort(int array[],int p, int r) {
    int q=0;
    if(p<r) {
    q=partition(array,p,r);
    sort(array,p,q-1);
    sort(array,q+1,r);
    }
    }
   
    public int partition(int[] a, int p, int r) {
    int x=a[r];
    int j=p-1;
    for (int i=p;i<=r-1;i++) {
    if (a[i]<=x) {
    j++;
    swap(a,j,i);
    }
    }
    swap(a,j+1,r);
    return j+1;
    }
   
    public void swap(int[] a, int i, int j) {
    int t = a[i];
    a[i] = a[j];
    a[j] = t;
    }
    }
   
    //二分查找类：适配者
    class BinarySearch {
    public int binarySearch(int array[],int key) {
    int low = 0;
    int high = array.length -1;
    while(low <= high) {
    int mid = (low + high) / 2;
    int midVal = array[mid];
    if(midVal < key) {
    low = mid +1;
    }
    else if (midVal > key) {
    high = mid -1;
    }
    else {
    return 1; //找到元素返回1
    }
    }
    return -1; //未找到元素返回-1
    }
    }
    //操作适配器：适配器
    class OperationAdapter implements ScoreOperation {
    private QuickSort sortObj; //定义适配者QuickSort对象
    private BinarySearch searchObj; //定义适配者BinarySearch对象
   
    public OperationAdapter() {
    sortObj = new QuickSort();
    searchObj = new BinarySearch();
    }
   
    public int[] sort(int array[]) {
    return sortObj.quickSort(array); //调用适配者类QuickSort的排序方法
    }
   
    public int search(int array[],int key) {
    return searchObj.binarySearch(array,key); //调用适配者类BinarySearch的查找方法
    }
    }

引入xml配置读取

import javax.xml.parsers.*;
   import org.w3c.dom.*;
   import org.xml.sax.SAXException;
   import java.io.*;
   class XMLUtil {
   //该方法用于从XML配置文件中提取具体类类名，并返回一个实例对象
   public static Object getBean() {
   try {
   //创建文档对象
    DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
    DocumentBuilder builder = dFactory.newDocumentBuilder();
    Document doc;
    doc = builder.parse(new File("config.xml"));
   
    //获取包含类名的文本节点
    NodeList nl = doc.getElementsByTagName("className");
    Node classNode=nl.item(0).getFirstChild();
    String cName=classNode.getNodeValue();
   
    //通过类名生成实例对象并将其返回
    Class c=Class.forName(cName);
    Object obj=c.newInstance();
    return obj;
    }
    catch(Exception e) {
    e.printStackTrace();
    return null;
    }
    }
    }

config.xml文件配置类名

<?xml version="1.0"?>
   <config>
   <className>OperationAdapter</className>
   </config>

客户端代码如下：

class Client {
   public static void main(String args[]) {
   ScoreOperation operation; //针对抽象目标接口编程
   operation = (ScoreOperation)XMLUtil.getBean(); //读取配置文件，反射生成对象
   int scores[] = {84,76,50,69,90,91,88,96}; //定义成绩数组
   int result[];
   int score;
  
   System.out.println("成绩排序结果：");
    result = operation.sort(scores);
   
    //遍历输出成绩
    for(int i : scores) {
    System.out.print(i + ",");
    }
    System.out.println();
   
    System.out.println("查找成绩90：");
    score = operation.search(result,90);
    if (score != -1) {
    System.out.println("找到成绩90。");
    }
    else {
    System.out.println("没有找到成绩90。");
    }
   
    System.out.println("查找成绩92：");
    score = operation.search(result,92);
    if (score != -1) {
    System.out.println("找到成绩92。");
    }
    else {
    System.out.println("没有找到成绩92。");
    }
    }
    }

适配器还有一种比较常见的叫缺省适配器

缺省适配器模式(Default Adapter Pattern)：当不需要实现一个接口所提供的所有方法时，可先设计一个抽象类实现该接口，并为接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可以选择性地覆盖父类的某些方法来实现需求，它适用于不想使用一个接口中的所有方法的情况，又称为单接口适配器模式。

示意图如下所示：

在缺省适配器模式中，包含如下三个角色：
● ServiceInterface（适配者接口）：它是一个接口，通常在该接口中声明了大量的方法。

● AbstractServiceClass（缺省适配器类）：它是缺省适配器模式的核心类，使用空方法的形式实现了在ServiceInterface接口中声明的方法。通常将它定义为抽象类，因为对它进行实例化没有任何意义。

● ConcreteServiceClass（具体业务类）：它是缺省适配器类的子类，在没有引入适配器之前，它需要实现适配者接口，因此需要实现在适配者接口中定义的所有方法，而对于一些无须使用的方法也不得不提供空实现。在有了缺省适配器之后，可以直接继承该适配器类，根据需要有选择性地覆盖在适配器类中定义的方法。

在JDK类库的事件处理包java.awt.event中广泛使用了缺省适配器模式，如WindowAdapter、
KeyAdapter、MouseAdapter等。下面我们以处理窗口事件为例来进行说明：在Java语言中，一般我们可以使用两种方式来实现窗口事件处理类，一种是通过实现WindowListener接口，另一种是通过继承WindowAdapter适配器类。如果是使用第一种方式，直接实现WindowListener接口，事件处理类需要实现在该接口中定义的七个方法，而对于大部分需求可能只需要实现一两个方法，其他方法都无须实现，但由于语言特性我们不得不为其他方法也提供一个简单的实现（通常是空实现），这给使用带来了麻烦。而使用缺省适配器模式就可以很好地解决这一问题，在JDK中提供了一个适配器类WindowAdapter来实现WindowListener接口，该适配器类为接口中的每一个方法都提供了一个空实现，此时事件处理类可以继承WindowAdapter类，而无须再为接口中的每个方法都提供实现。
如图所示：

适配器模式总结

1. 主要优点

(1) 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无须修改原有结构。

(2) 增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对于客户端类而言是透明的，而且提高了适配者的复用性，同一个适配者类可以在多个不同的系统中复用。

(3) 灵活性和扩展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，完全符合“开闭原则”。

2. 主要缺点

要在适配器中置换适配者类的某些方法比较麻烦。如果一定要置换掉适配者类的一个或多个方法，可以先做一个适配者类的子类，将适配者类的方法置换掉，然后再把适配者类的子类当做真正的适配者进行适配，实现过程较为复杂