1 模式动机

    在软件开发过程中，通常遇到新需求要使用到某个数据模型或者某个逻辑类接口，但是此类无法直接使用，最常见的就是协议不匹配或者已有逻辑不完全满足新需求。最苦恼的是无法修改该类的代码，就算能修改，改变了以前稳定的代码会带来一定的风险。这个时候有没有一种方法，能够避免风险，又能方便的进行扩展完成新需求呢。答案就是进行封装，不改变以前稳定的代码，扩展新接口来实现新需求逻辑。当然，新接口的逻辑会调用以前的代码，并对外部保持隐藏，这样就能在保持系统稳定的同时实现新需求。

2 模式定义

   适配器模式(Adapter Pattern)：将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式有类适配器和对象适配器两种实现。

3 类适配器

    将原始类通过继承实现新的接口，叫做类适配器。适配类将原始API转换成目标API。 

4 对象适配器 

    与类适配器模式一样，对象适配器模式把被适配的类API转换成目标类API，不同的是，对象适配器模式不是使用继承关系连接到Adaptee类，而是使用委派关系连接到Adaptee类。

5 适配器选择

    类适配器直接继承Adaptee，就不能再处理Adaptee的子类。

    对象适配器可以把多种不同的源适配到同一个目标。换言之，同一个适配器可以把源类或者它的子类都适配到目标接口。

    类适配器可以重定义Adaptee部分行为，相当于子类覆盖父类的部分实现方法。

   建议：尽量使用对象适配器的实现方式，多用合成/聚合，少用继承。当然，具体问题具体分析，根据需要来选用实现方式，最适合才是最好的。

6 默认适配器

    实现方式：默认适配器实现指定的接口，并为接口中每个方法提供一个空的实现方式。

    默认适配器为一个接口提供默认实现，这样它的子类型可以更方便的选择实现需要的接口，而不是实现所有接口。

    默认适配器还有一个作用，可以用来减少参数空判断的逻辑代码。参数不为空时，采用具体逻辑类处理，但当参数为空时，可以提供一个空的实现类来执行。这样在工程代码中可以减少很多空指针的保护判断，使得代码结构更加紧凑。

7 优缺点

    适配器模式优点：

    1 降低对已有代码的影响。改变已有的代码意味着增大不稳定的风险，增加新功能尽量通过扩展代码实现。在不改变原来代码的基础上，通过扩展代码实现新需求，对稳定性有很大帮助。

    2 更好的复用度。将以前不能使用的接口通过适配，变成可以使用的接口。

    3 更好的扩展性。在已有功能的基础上，可以更方便的扩展新功能。

    适配器模式缺点：

    1 过多的使用适配器，会让系统非常凌乱，不易于整体把握。如果系统适配太多，可以考虑对系统进行重构。例如：看到调用的是A接口，但实际上内部调用的是B接口的实现。

8 总结

    适配器模式是为了解决部分场景下的问题而生成的。

    1 已有的接口不能满足需求，但又不能修改已有的代码，这样只能新增实现代码。例如：使用已经稳定的代码，集成第三方框架。

    2 为了满足封装原则，单一职责原则以及复用原则，需要将适配逻辑独立封装，以便复用。至于目标接口Target，可以根据情况选择使用。

适配器模式