接口不能用？行，我帮你适配

一、概述

适配器模式（Adapter），是23种设计模式中的结构型模式之一；它就像我们电脑上接口不够时，需要用到的拓展坞，起到转接的作用。它可以将新的功能和原先的功能连接起来，使由于需求变动导致不能用的功能，重新利用起来。

上图的Mac上，只有两个typec接口，当我们需要用到USB、网线、HDMI等接口时，这就不够用了，所以我们需要一个拓展坞来增加电脑的接口

言归正传，下面来了解下适配器模式中的角色：请求者（client）、目标角色（Target）、源角色（Adaptee）、适配器角色（Adapter），这四个角色是保证这个设计模式运行的关键。

• client：需要使用适配器的对象，不需要关心适配器内部的实现，只对接目标角色。
• Target：目标角色，和client直接对接，定义了client需要用到的功能。
• Adaptee：需要被进行适配的对象。
• Adapter：适配器，负责将源对象转化，给client做适配。

二、入门案例

适配器模式也分两种：对象适配器、类适配器。其实两种方式的区别在于，适配器类中的实现，类适配器是通过继承源对象的类，对象适配器是引用源对象的类。

当然两种方式各有优缺点，咱分别来说下；

类适配器：由于采用继承模式，在适配器中可以重写Adaptee原有的方法，使得适配器可以更加灵活；但是有局限性，Java是单继承模式，所以适配器类只能继承Adaptee，不能在额外继承其他类，也导致Target类只能是接口。

对象适配器：这个模式规避了单继承的劣势，将Adaptee类用引用的方式传递给Adapter，这样可以传递的是Adaptee对象本身及其子类对象，相比类适配器更加的开放；但是也正是因为这种开放性，导致需要自己重新定义Adaptee，增加额外的操作。

类适配器UML图

对象适配器UML图

下面，是结合上面电脑的场景，写的一个入门案例，分别是四个类：Client、Adaptee、Adapter、Target，代表了适配器模式中的四种角色。

/**
 * @author 往事如风
 * @version 1.0
 * @date 2023/5/9 15:54
 * @description：源角色
 */
public class Adaptee {
    /**
     * 需要被适配的适配的功能
     * 以Mac笔记本的typec接口举例
     */
    public void typeC() {
        System.out.println("我只是一个typeC接口");
    }
}

/**
 * @author 往事如风
 * @version 1.0
 * @date 2023/5/9 15:57
 * @description：目标接口
 */
public interface Target {

    /**
     * 定义一个转接功能的入口
     */
    void socket();
}

/**
 * @author 往事如风
 * @version 1.0
 * @date 2023/5/9 16:00
 * @description：适配器
 */
public class Adapter extends Adaptee implements Target {

    /**
     * 实现适配功能
     * 以Mac的拓展坞为例，拓展更多的接口：usb、typc、网线插口...
     */
    @Override
    public void socket() {
        typeC();
        System.out.println("新增usb插口。。。");
        System.out.println("新增网线插口。。。");
        System.out.println("新增typec插口。。。");
    }
}

/**
 * @author 往事如风
 * @version 1.0
 * @date 2023/5/9 15:52
 * @description：请求者
 */
public class Client {

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

这个案例比较简单，仅仅是一个入门的demo，也是类适配器模式的案例，采用继承模式。在对象适配器模式中，区别就是Adapter这个适配器类，采用的是组合模式，下面是对象适配器模式中Adapter的代码；

/**
 * @author 往事如风
 * @version 1.0
 * @date 2023/5/9 16:00
 * @description：适配器
 */
public class Adapter implements Target {

    private Adaptee adaptee;

    public Adapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }

    /**
     * 实现适配功能
     * 以Mac的拓展坞为例，拓展更多的接口：usb、typc、网线插口...
     */
    @Override
    public void socket() {
        adaptee.typeC();
        System.out.println("新增usb插口。。。");
        System.out.println("新增网线插口。。。");
        System.out.println("新增typec插口。。。");
    }
}

三、运用场景

其实适配器模式为何会存在，全靠“烂代码”的衬托。在初期的设计上，一代目没有考虑到后期的兼容性问题，只顾自己一时爽，那后期接手的人就会感觉到头疼，就会有“还不如重写这段代码的想法”。但是这部分代码往往都是经过N代人的充分测试，稳定性比较高，一时半会还不能对它下手。这时候我们的适配器模式就孕育而生，可以在不动用老代码的前提下，实现新逻辑，并且能做二次封装。这种场景，我在之前的系统重构中深有体会，不说了，都是泪。

当然还存在一种情况，可以对不同的外部数据进行统一输出。例如，写一个获取一些信息的接口，你对前端暴露的都是统一的返回字段，但是需要调用不同的外部api获取不同的信息，不同的api返回给你的字段都是不同的，比如企业工商信息、用户账户信息、用户津贴信息等等。下面我对这种场景具体分析下；

首先，我定义一个接口，接收用户id和数据类型两个参数，定义统一的输出字段。

/**
 * @author 往事如风
 * @version 1.0
 * @date 2023/5/10 11:03
 * @description
 */
@RestController
@RequestMapping("/user")
@RequiredArgsConstructor
public class UserInfoController {

    private final UserInfoTargetService userInfoTargetService;

    @PostMapping("/info")
    public Result<DataInfoVo> queryInfo(@RequestParam Integer userId, @RequestParam String type)