适配器设计模式笔记

定义

        将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。
在适配器模式中，我们通过增加一个新的适配器类来解决接口不兼容的问题，使得原本没有任何关系的类可以协同工作。

        根据适配器类与适配者类的关系不同，适配器模式可分为对象适配器和类适配器两种，在对象适配器模式中，适配器与适配者之间是关联关系；在类适配器模式中，适配器与适配者之间是继承（或实现）关系。

类型————结构型

分类

1.类适配器

2.对象适配器

角色

目标抽象类：Target，该角色把其他类转换为我们期望的接口，可以是一个抽象类或接口，也可以是具体类。
被适配者: Adaptee ，原有的接口，也是希望被适配的接口。
适配器： Adapter, 将被适配者和目标抽象类组合到一起的类。
缺省适配器模式(Default Adapter Pattern)：当不需要实现一个接口所提供的所有方法时，可先设计一个抽象类实现该接口，并为接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可以选择性地覆盖父类的某些方法来实现需求，它适用于不想使用一个接口中的所有方法的情况，又称为单接口适配器模式。缺省适配器模式是适配器模式的一种变体，其应用也较为广泛。在JDK类库的事件处理包java.awt.event中广泛使用了缺省适配器模式，如WindowAdapter、KeyAdapter、MouseAdapter等。

public interface Usb {
    public void work();
}

public class UsbWork1 implements Usb{

    @Override
    public void work() {
        System.out.println("this is work1");
    }
}

public interface Typec {
    public void typecWork();
}

public class NetBookTypec implements Typec{
    public void typecWork() {
        System.out.println("typec");
    }
}

public class charge implements Usb{
    private Typec typec;

    public charge (Typec typec){
          this.typec=typec;
    }
    @Override
    public void work() {
        typec.typecWork();
    }
}

类适配器的大致结构图如下所示，目标接口定义规范，适配器类相当于多了一层包装，可以调用到被适配者的方法。但是具体去实现一个目标接口的实现类是不能接触到被适配者类的属性和方法的。这样我们即可在新接口 Target 中适配旧的接口或类，然后供别人使用。
也就是说：我打个比方，有的人喜欢看电子档书籍，有的人喜欢看纸质档。
但是已有的就只是电子档，所以我们要增加一个步骤（在这里就是增加一个新接口），把电子档的书籍打印成纸质书籍给别人使用。

总结
主要优点
将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无须修改原有结构。
增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对于客户端类而言是透明的，而且提高了适配者类的复用性，同一个适配者类可以在多个不同的系统中复用。
灵活性和扩展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，符合“开闭原则”。
主要缺点
会让系统看起来很复杂，不易维护（因为需要从全局考虑）
增加代码的阅读难度
适配器模式最好在详细设计不要考虑它，它不是为了解决还处在开发阶段的问题，而是解决正在服役的项目问题。

适用场景
想要使用一个已经存在的类，但是它却不符合现有的接口规范，导致无法直接去访问，这时创建一个适配器就能间接去访问这个类中的方法。
我们有一个类，想将其设计为可重用的类，我们可以创建适配器，将这个类来适配其他没有提供合适接口的类。
优点

和其他模式的对比
适配器模式和装饰者模式：装饰者模式是对以前的类进行进一步的封装与增强，目的是一层一层的增加功能，而适配器模式主要是为了协调多个调用者不同的调用方式而设计出来的。
适配器模式和外观模式：都是对现有类的封装，外观模式定义了新的接口，适配器则是复用已有的接口，适配器是两个接口协调工作，而外观模式则是为了别人使用的方便，提供了一个比较易用的接口

一般来说，适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷。应用这种模式算是“无奈之举”。如果在设计初期，我们就能协调规避接口不兼容的问题，那这种模式就没有应用的机会了。

1.封装有缺陷的接口设计
假设我们依赖的外部系统在接口设计方面有缺陷（比如包含大量静态方法），引入之后会影响到我们自身代码的可测试性。为了隔离设计上的缺陷，我们希望对外部系统提供的接口进行二次封装，抽象出更好的接口设计，这个时候就可以使用适配器模式了。
2.统一多个类的接口设计
某个功能的实现依赖多个外部系统（或者说类）。通过适配器模式，将它们的接口适配为统一的接口定义，然后我们就可以使用多态的特性来复用代码逻辑。
3.替换依赖的外部系统
当我们把项目中依赖的一个外部系统替换为另一个外部系统的时候，利用适配器模式，可以减少对代码的改动。
4.兼容老版本接口
在做版本升级的时候，对于一些要废弃的接口，我们不直接将其删除，而是暂时保留，并且标注为 deprecated，并将内部实现逻辑委托为新的接口实现。这样做的好处是，让使用它的项目有个过渡期，而不是强制进行代码修改。这也可以粗略地看作适配器模式的一个应用场景。
5.适配不同格式的数据
适配器模式主要用于接口的适配，实际上，它还可以用在不同格式的数据之间的适配。比如，把从不同征信系统拉取的不同格式的征信数据，统一为相同的格式，以方便存储和使用。再比如，Java 中的 Arrays.asList() 也可以看作一种数据适配器，将数组类型的数据转化为集合容器类型。