案例分析：设计模式与代码的结构特性

设计模型选择适配器模式

一、适配器模型定义

　　适配器模式（Adapter Pattern），是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。

　　这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。

　　在适配器模式中，我们通过增加一个新的适配器类来解决接口不兼容的问题，使得原本没有任何关系的类可以协同工作。根据适配器类与适配者类的关系不同，适配器模式可分为对象适配器和类适配器两种，在对象适配器模式中，适配器与适配者之间是关联关系；在类适配器模式中，适配器与适配者之间是继承（或实现）关系。

 

二、角色

　　Target（目标抽象类）：目标抽象类定义客户所需接口，可以是一个抽象类或接口，也可以是具体类。

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

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

　　缺省适配器模式(Default Adapter Pattern)：当不需要实现一个接口所提供的所有方法时，可先设计一个抽象类实现该接口，并为接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可以选择性地覆盖父类的某些方法来实现需求，它适用于不想使用一个接口中的所有方法的情况，又称为单接口适配器模式。缺省适配器模式是适配器模式的一种变体，其应用也较为广泛。在JDK类库的事件处理包java.awt.event中广泛使用了缺省适配器模式，如WindowAdapter、KeyAdapter、MouseAdapter等。

三、典型的应用范例

笔记本通过读卡去读取TF卡，先模拟计算机读取SD卡：

1.先创建一个SD卡的接口：

public interface SDCard {
    //读取SD卡方法
    String readSD();
    //写入SD卡功能
    int writeSD(String msg);
}

2、创建SD卡接口的实现类，模拟SD卡的功能：

public class SDCardImpl implements SDCard {
    @Override    
    public String readSD() {
        String msg = "sdcard read a msg :hello word SD";
        return msg;  
    }
    @Override  
    public int writeSD(String msg) {      
        System.out.println("sd card write msg : " + msg);    
        return 1;   
    }
}

3、创建计算机接口，计算机提供读取SD卡方法：

public interface Computer {    
    String readSD(SDCard sdCard);
}

4、创建一个计算机实例，实现计算机接口，并实现其读取SD卡方法：

public class ThinkpadComputer implements Computer {
    @Override    
    public String readSD(SDCard sdCard) {        
        if(sdCard == null)throw new NullPointerException("sd card null");        
        return sdCard.readSD();    
    }
}

5、这时候就可以模拟计算机读取SD卡功能：

public class ComputerReadDemo {    
    public static void main(String[] args) {        
        Computer computer = new ThinkpadComputer();        
        SDCard sdCard = new SDCardImpl();       
        System.out.println(computer.readSD(sdCard));    
    }
}

接下来在不改变计算机读取SD卡接口的情况下，通过适配器模式读取TF卡：

1、创建TF卡接口：

public interface TFCard {    
    String readTF();    
    int writeTF(String msg);
}

2、创建TF卡实例：

public class TFCardImpl implements TFCard {    
    @Override    
    public String readTF() {        
        String msg ="tf card reade msg : hello word tf card";        
        return msg;    
    }    
    @Override    
    public int writeTF(String msg) {        
        System.out.println("tf card write a msg : " + msg);        
        return 1;    
    }
}

3、创建SD适配TF （也可以说是SD兼容TF，相当于读卡器）：

实现SDCard接口，并将要适配的对象作为适配器的属性引入。

public class SDAdapterTF implements SDCard {    
    private TFCard tfCard;    
    public SDAdapterTF(TFCard tfCard) {        
        this.tfCard = tfCard;    
    }    
    @Override    
    public String readSD() {        
        System.out.println("adapter read tf card ");        
        return tfCard.readTF();    
    }    
    @Override    
    public int writeSD(String msg) {        
        System.out.println("adapter write tf card");        
        return tfCard.writeTF(msg);    
    }
}

4、通过上面的例子测试计算机通过SD读卡器读取TF卡：

public class ComputerReadDemo {    
    public static void main(String[] args) {        
        Computer computer = new ThinkpadComputer();        
        SDCard sdCard = new SDCardImpl();        
        System.out.println(computer.readSD(sdCard));        
        System.out.println("====================================");        
        TFCard tfCard = new TFCardImpl();        
        SDCard tfCardAdapterSD = new SDAdapterTF(tfCard);        
        System.out.println(computer.readSD(tfCardAdapterSD));    
    }
}

输出：

sdcard read a msg :hello word SD
====================================
adapter read tf card 
tf card reade msg : hello word tf card

在这种模式下，计算机并不需要知道具体是什么卡，只需要负责操作接口即可，具体操作的什么类，由适配器决定。

UML图

 

 

 四、适配器模型优点及适用场景

　　优点：

1. 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无须修改原有结构。
2. 增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对于客户端类而言是透明的，而且提高了适配者的复用性，同一个适配者类可以在多个不同的系统中复用。
3. 灵活性和扩展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，完全符合“开闭原则”

　　适用场景：

1. 系统需要使用一些现有的类，而这些类的接口（如方法名）不符合系统的需要，甚至没有这些类的源代码。
2. 想创建一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。