定义
适配器模式(Adapter Pattern)：讲一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
通俗理解
现在很多手机都有快充的功能，可以随时随地实现“充电五分钟，通话两小时”的效果，这在四五年前都是一个不可以想象的事情。但是，要实现这个效果可不容易，需要达到三个标准才能实现快充。第一：手机支持快充，快充不是电压、电流上去了就是快充了，而要手机cpu等相关的配合；第二：手机的充电口必须是type-c接口，type-c是新的usb接口，可以传输更高的电流；第三：充电器必须是快充的充电器，充电器至少2A才能快充，如果只是500mA就不需要想了。
很多新的手机都是都能满足这三个条件。当我们很开心地把手机买回来之后，发现以前的充电线用不了了。以前的线是micro-usb的，但是新手机的接口是type-c的，两个接口完全不一样，怎么怼都怼不进去，难道以前上百条的充电线都要扔掉？
聪明的你一定想到了，从X宝上买一个转换口，micro-usb转type-c的，有了这个转换口就能够用以前的micro-usb的线给手机充电了。
适配器模式就是这个转换器，把原来的micro-usb转换成type-c，然后提供给新的手机使用。我们要写的代码，就是写这个转换头的代码。当然，很多例子都会用充电器来做比喻，所以适配器模式也叫变压器模式，同时也是包装模式（Wrapper Pattern)
示例
业务按这个转换头做示例。
渣渣程序
micro-usb接口和实现
public interface IMicroUsb {
void slowFilling();
}
public class MicroUsbImpl implements IMicroUsb {
public void slowFilling() {
System.out.println("这个是micro-usb的接口，可以慢充");
}
}
type-c接口和实现
public interface ITypeC {
void quickFilling();
}
public class TypeCImpl implements ITypeC {
public void quickFilling() {
System.out.println("这是type-c的接口，可以快充");
}
}
主程序
public class Main {
public static void main(String[] args) {
ITypeC typeC = new TypeCImpl();
typeC.quickFilling();//这是type-c的接口，可以快充
IMicroUsb microUsb = new MicroUsbImpl();
microUsb.slowFilling();//这个是micro-usb的接口，可以慢充
}
}
现在主程序里面，快充的接口只能充快充的电，慢充的接口只能充面慢充的电，我们需要的是在typeC方法当中，去充慢充的电（好绕）。
程序上表示为，我们还是调用typeC.quickFilling();，但是输出的结果是：这个是micro-usb的接口，可以慢充
千万不要这么做
public class TypeCImpl implements ITypeC {
IMicroUsb microUsb = new MicroUsbImpl();
public void quickFilling() {
microUsb.slowFilling();
//System.out.println("这是type-c的接口，可以快充");
}
}
这是不允许的，原因有
- 完全改变了
quickFilling()的语义，相当于把慢充的micro-usb的头切掉，换成type-c的一样，往后只能给type-c充电，而micro-usb的设备就别想了； -
microUsb作为一个强耦合变量，类和类的耦合性太高，如果MicroUsbImpl坏了，丢弃不用，那么TypeCImpl也用不了； - 主程序没有选择的余地，只能选择经过micro-usb改造的type-c；
- 违反开闭原则，写多了程序，就会发现，改以前的代码，基本上是按下葫芦浮起瓢，改了一个bug就会变成了很多个bug，当然如果有良好的测试用例，还是得大胆重构。
优化
类适配器
类图
程序
其他程序不变，写一个适配器。
适配器
public class MicroUsbToTypeC extends MicroUsbImpl implements ITypeC{
public void quickFilling() {
super.slowFilling();
}
}
主程序
public class Main {
public static void main(String[] args) {
ITypeC typeC = new MicroUsbToTypeC();
typeC.quickFilling();//这个是micro-usb的接口，可以慢充
}
}
对象适配器
类图
程序
其他程序不变，写一个适配器。
对象适配器
public class MicroUsbToTypeC implements ITypeC{
private IMicroUsb microUsb;
public MicroUsbToTypeC(IMicroUsb microUsb) {
this.microUsb = microUsb;
}
public IMicroUsb getMicroUsb() {
return microUsb;
}
@Override
public void quickFilling() {
microUsb.slowFilling();
}
}
主程序
public class Main {
public static void main(String[] args) {
ITypeC typeC = new MicroUsbToTypeC(new MicroUsbImpl());
typeC.quickFilling();
}
}
通过上面的两种方式，就可以实现原程序一个都不改的情况下，添加新的功能（其实就是加新类，只不过这个类好听一点）
两种适配器的比较[1]
优先使用对象组合，而不是继承
| 条件 | 类适配器 | 对象适配器 |
|---|---|---|
| 是否适配不同的继承类 | 不可以（源类的子类不行） | 可以（多态） |
| 修改原类功能 | 可以（多态，很危险） | 不可以 |
| 结构性质 | 静态 | 动态 |
| 耦合度 | 高 | 低 |
| 是否违反单一职责原则 | 违反（满足两个接口） | 不违反 |
优点
- 目标类和适配器类解耦，不需要修改原来的结构；
- 增加类的透明性，高层的程序只需要调用就可以了，不需要知道他们是怎么适配过去的；
- 提高类的复用度，本来的那个类不会因为加入新类而用不来；
- 灵活性好，不用适配了，扔掉就行；
- 类适配器：子类可以修改源类的方法；
- 对象适配器：多个适配者适配到同一个目标；可以适配适配者的子类
缺点
- 类适配器：只能适配一个适配类；适配类不能为final；目标类必须是接口；
- 对象适配器：源类的方法麻烦
应用场景
- IAdaptee不能修改了，只能这么玩
- 走投无路时候，一开始设计系统的时候不要考虑这个，不然就是作死，这个是给后面补救使用的。
程序
https://www.jianshu.com/p/1ea66bc26b02
-
来着书籍《设计模式 从入门到精通》/杨帆，王钧玉、孙更新编著.——北京：电子工业出版社，2010.8 ↩
