前语：不要为了读文章而读文章，一定要带着问题来读文章，勤思考
序言
在以前学习适配器模式时，有个经典例子：就是有些电器的工作电压不是220V， 比如电脑工作电压20V,但是我们家庭用电的电压是220。怎么让20V的电脑在220V的电压下工作，这就需要一个电源适配器——俗称充电器或变压器。有了这个电源适配器 家庭的用电电压跟电脑的用电电压 即可兼容。
# 适配器模式
定义：将一个接口转换成客户所希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为为包装器（Wrapper）。适配器模式既可以作为类结构性模式，也可以作为对象型结构性模式。
Target(目标抽象类)：目标抽象类定义客户所需的接口，可以是一个抽象类或接口，也可以是一个具体的类。
**Adapter（适配器类）: **适配器可以调用另外一个接口，作为一个转换器，对Adaptee和Target进行适配，适配器类是适配器模式的核心。
Adaptee(适配者类) ：适配者即被适配的角色，它定义了已存在的接口，这个接口需要适配。一般是一个具体的类，包含了客户希望使用的业务方法，在某些情况下可能没有适配者类的源代码。
在适配器模式结构图我们可以看到 Adapter（适配器）和Adaptee(适配者)是有一种关联的，这种关联可以是继承关系，也可以是一种组合关系。继承关系的我们一般称为类适配器模式; 组合关系的称为对象适配器模式。
类适配器模式
定义一个需要被适配的类。
/**
- @program
- @Desc Adaptee（适配者）
- @Author 游戏人日常
- @CreateTime 2019/07/08--14:49
*/
public class Adaptee {
public void specificRequest(){
System.out.println("将需要被适配的方法");
}
}
</pre>
定义一个目标接口。
/**
- @program
- @Desc 目标接口
- @Author 游戏人日常
- @CreateTime 2019/07/08--14:53
*/
public interface Target {
public void request();
}
</pre>
定义适配器类， 因为是类适配器模式，所以我们需要继承Adaptee类。
/**
- @program
- @Desc Adapter（适配者）
- @Author 游戏人日常
- @CreateTime 2019/07/08--14:57
*/
public class Adapter extends Adaptee implements Target {
@Override
public void request() {
specificRequest();
}
@Override
public void specificRequest() {
//这里可以加下其他操作
super.specificRequest();
//这里可以加下其他操作
}
}
</pre>
客户端测试。
public static void main(String args []){
Target adapter=new Adapter();
adapter.request();
}
</pre>
输出结果 ：
将需要被适配的方法
</pre>
这里我们可以看到适配器（Adapter）继承了适配者（Adaptee），然后实现了目标接口（Target）。这样使目标接口跟适配者的接口就关联起来了， 客户端通过调用适配器的方法，从而达到调用了适配者所被适配的方法。
对象适配器模式
对象适配器模式跟类适配器模式所不同的就是适配器（Adapter）类是基于继承的，而对象适配器是基于组合的。其他的Target、Adaptee不变。
定义适配器类。
/**
- @program
- @Desc Adapter（适配者）
- @Author 游戏人日常
- @CreateTime 2019/07/08--14:57
*/
public class Adapter implements Target {
private Adaptee adaptee =new Adaptee();
@Override
public void request() {
adaptee.specificRequest();
}
}
</pre>
客户端测试。
public static void main(String args []){
Target adapter=new Adapter();
adapter.request();
}
</pre>
输出结果 ：
将需要被适配的方法
</pre>
一般常用的就是对象适配器模式，很少用类适配器。 还有一种双向适配器模式，就是（Adapter）适配器包含对目标类（Target）和适配者类（Adaptee）两个引用。目标类可以通过适配器（Adapter）调用适配者（Adaptee中的方法， 适配者类也可以通过适配器调用目标类的方法。UML类图如下。
适配器（Adapter）类一般写法如下：
/**
- @program
- @Desc Adapter（适配者）
- @Author 游戏人日常
- @CreateTime 2019/07/08--14:57
*/
public class Adapter implements Target , Adaptee {
//同时对适配者和目标类的引用
private Target target;
private Adaptee adaptee;
public Adapter(Target target) {
this.target = target;
}
public Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
@Override
public void request() {
adaptee.specificRequest();
}
@Override
public void specificRequest() {
target.request();
}
}
</pre>
在实际的开发中很少使用双向适配器。
缺省适配器
缺省适配器模式是适配器模式一种变体。
定义：当不需要实现一个接口所提供的所有方法时，可以设计一个抽象类实现该接口，并为每个接口提供一个默认实现，那么该抽象类的子类可以选择性覆盖父类中的方法，它适用于不想使用一个接口中的所有方法的情况，又称为单接口适配器模式。
简单的理解就是当适配者（Adaptee）有大量的方法时，那么每个适配器（Adapter）都要去实现接口中的这些方法，这样就感觉太费劲。所以这种情况下，可以考虑实现个默认的适配器，然后根据实际目标角色接口的类集成这个默认适配器，然后选择性的实现默认适配器中的一些方法。
缺省适配器模式结构如下图：
**ServiceInterface(适配者接口) **：是一个接口，里面包含大量的方法。
**AbstractServiceClass(缺省适配器类) **：实现了ServiceInterface中声明的方法， 通常定义为抽象类。
**ConcreteServiceClass(具体业务类) **：它是缺省适配器的子类，在没有引用适配器之前，它需要实现适配者（ServiceInterface）所有的方法， 有了缺省适配器类后，就可以有选择性的覆盖适配器类中的方法。
总结
适配器模式总共列出四种：类适配器模式、 对象适配器模式 、 双向适配器模式 、 缺省适配器模式。
- 类适配器模式 ：适配器（Adapter）跟适配者（Adaptee）是一种继承关系。
- 对象适配器模式：适配器（Adapter）跟适配者（Adaptee）是一种组合关系。
- 双向适配器模式 ：双向适配器是对象适配器模式的一种变体， 该模式的适配器（Adapter）不仅引用了适配者（Adaptee）,还对目标类（Target）引用。所以这种模式目标类和适配者之间互相适配。
- 缺省适配器模式：当适配者接口中出现大量的方法时，就可以考虑这种模式。
1、优点
类适配器模式和对象适配器模式都具有的优点：
- 将目标类（Target）和 适配者类（Adaptee）解耦， 引用一个适配器类（Adapter）就可以对适配者进行重用。
- 增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对客户端来而言是透明的，而且提高了适配者的复用性，同一个适配者类可以在多个不同的系统中复用。
对象适配器模式优点：
- 一个对象适配器可以把多个适配者适配到同一目标。
- 可以适配一个适配者的子类，由于适配器和适配者之间是组合关系，根据“里氏代换原则”，适配者的子类也可以通过该适配器进行适配。
2、缺点
类适配器模式缺点：
- 因为Java不支持多重继承，一次最多适配一个适配者类，不能同时适配多个适配者。
- 适配者类不能为最终类，即适配者类不能用final关键字修饰。
- 类适配器模式中的目标类只能为接口，不能为类。
对象适配器模式缺点：
与类适配器模式相比，要在适配器中置换适配者类的某些方法比较麻烦（因为类适配器模式是基于继承的，可以重写适配者类的方法，对象适配器模式则不能），如果一定要置换掉适配者类的方法，可以先做一个适配者的子类，将适配者类的方法置换掉，然后再把适配者的子类当作真正的适配者进行适配，实现过程较为复杂。
3、适用场景
- 系统需要使用一些现有的类，而这些类的接口（如方法名）不符合需要。
- 想创建一个可以重用的类，用于与一些彼此之间没有太大的关联的一些类，包括一些可能再将来引进的类一起工作。
有任何问题，欢迎大家留言评论，大家可以关注我的主页，定期更新技术干货以及面试专题！
