“Head First 设计模式“ ：适配器模式

适配器模式

适配器模式定义：将一个类的接口，转化成客户期望的另一个接口，适配器让原本接口不兼容的类可以合作无间。对象适配器类图如下：

角色说明：
● Target，目标接口
● Adapter，适配器
● Adaptee，被适配对象
● Client，客户端

客户使用适配器的过程如下：
● 客户通过目标接口调用适配器的方法对适配器发出请求。
● 适配器使用被适配者接口把请求转换成被适配者的一个或多个调用接口。
● 客户接收到调用的结果，但并未察觉这一切是适配器在起转换作用。

适配器模式的优点：
● 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无需修改原有结构。
● 增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对于客户端类而言是透明的，而且提高了适配者的复用性，同一适配者类可以在多个不同的系统中复用。
● 灵活性和扩展性都非常好，通过使用配置文件，可以很方便的更换适配器，也可以在不修改原有代码的基础上 增加新的适配器，完全复合开闭原则。

适配器模式的缺点：
● 一次最多只能适配一个适配者类，不能同时适配多个适配者。
● 目标抽象类只能为接口，不能为类，其使用有一定的局限性。

适配器模式的使用场景：
● 系统需要使用一些现有的类，而这些类的接口不符合系统的需要，甚至没有这些类的源代码
● 创建一个可以重复使用的类，用于和一些彼此之间没有太大关联的类，包括一些可能在将来引进的类一起工作

扩展：
● 双向适配器，两个接口互相转换，省略类图，说明
● 类适配器，Java不支持多重继承，所以省略类图，说明

案例1：假设已有一个软件系统，你希望它能和一个新的厂商类库搭配使用，但是这个新的厂商所设计出来的接口不同于旧厂商的接口。怎么实现好，如下:

解决办法，我们不改目前代码的情况下，加一个适配器（Adapter）类，适配器对用户来说透明的，如下：

案例2：有鸭子接口（鸭子能飞，呱呱叫），火鸡接口（可以飞点，姑姑叫），假设我们缺鸭子对象，用火鸡来冒充，类图如下：

案例3：JDK中早起版本的Collection集合都实现了一个elements()，该方法返回一个包含集合里的每一个元素的枚举，新版本的JDK里用Iterator来代替了，而且Iterator还提供了删除元素的能力，假设有一个预留代码，这个代码爆出枚举接口，但是我们想新代码中使用迭代器，我们用适配器模式来解决，如下：

案例4： JDK里IO框架里的InputStreamReader，OutputStreamReader使用的是适配器模式，如下：

说明：
● InputStream，OutputStream是被适配对象。
● Reader，Writer是目标接口。
● StreamEncoder是中间类，byte类型转字符时需要编码转换的，贵类的作用就是这个。
● InputStreamReader，OutputStreamReader是适配器类。

设计原则："最少知识"原则：只和你的密友谈话。