本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励金。
小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
其他设计模式介绍
创建型：
工厂方法
抽象工厂
原型
结构型：
适配器
桥接模式
组合模式
装饰模式
外观模式
享元模式
代理模式
行为型：
职责链
命令
解释器
迭代器
中介者
备忘录
状态模式
策略模式
模板方法
访问者
定义
把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法一起工作的两个类能够在一起工作。
该模式的主要优点如下。
- 客户端通过适配器可以透明地调用目标接口。
- 复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类。
- 将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题。
- 在很多业务场景中符合开闭原则。
其缺点是：
- 适配器编写过程需要结合业务场景全面考虑，可能会增加系统的复杂性。
- 增加代码阅读难度，降低代码可读性，过多使用适配器会使系统代码变得凌乱。
UML
在上图中可以看出：
- 冲突：Target期待调用Request方法，而Adaptee并没有（这就是所谓的不兼容了）。
- 解决方案：为使Target能够使用Adaptee类里的SpecificRequest方法，故提供一个中间环节Adapter类 （继承Adaptee & 实现Target接口） ，把Adaptee的API与Target的API衔接起来（适配）。
Adapter与Adaptee是继承关系，这决定了这个适配器模式是类的
适配器模式（Adapter）包含以下主要角色。
- 目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。
- 适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。
- 适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。
举个例子
interface Target {
//这是源类Adapteee没有的方法
fun request()
}
open class Adaptee {
//适配器Adapter继承自Adaptee，同时又实现了目标(Target)接口。
fun specRequest() {}
}
class Adapter : Adaptee(), Target {
//目标接口要求调用Request()这个方法名，但源类Adaptee没有方法Request()
//因此适配器补充上这个方法名
//但实际上Request()只是调用源类Adaptee的SpecificRequest()方法的内容
//所以适配器只是将SpecificRequest()方法作了一层封装，封装成Target可以调用的Request()而已
override fun request() {
specRequest()
}
}
fun main() {
val ap: Target = Adapter()
ap.request()
}
应用场景
适配器模式（Adapter）通常适用于以下场景。
- 以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
- 使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同。
