你笔记本上的那个拖在外面的黑盒子就是个适配器，一般你在中国能用，在日本也能用，虽然两个国家的的电源电压不同，中国是 220V，日本是 110V，但是这个适配器能够把这些不同的电压转换为你需要的 36V 电压，保证你的笔记本能够正常运行，那我们在设计模式中引入这个适配器模式是不是也是这个意思呢？是的，一样的作用，两个不同接口，有不同的实现，但是某一天突然上帝命令你把 B 接口转换为 A 接口，怎么办？继承，能解决，但是比较傻，而且还违背了 OCP 原则，怎么办？好在我们还有适配器模式。
适配器的通用类图是这个样子滴：
首先声明，这个不是我画的，这是从 Rational Rose 的帮助文件中截取的，这个类图也很容易理解， Target 是一个类（接口），Adaptee 是一个接口，通过 Adapter 把 Adaptee 包装成 Target 的一个子类（实现类），注意了这里用了个名词包装（Wrapper），那其实这个模式也叫做包装模式(Wrapper)，但是包装模式可不知一个，还包括了以后要讲的装饰模式。我来讲个自己的一个经验，让大家可以更容易了解这个适配器模式，否则纯讲技术太枯燥了，技术也可以有娱乐的嘛。
总公司发起一个项目，公司一共有 700 多号人，包括子公司，这个项目还是比较简单的，分为三大模块：人员信息管理，薪酬管理，职位管理，其中人员管理这块就用到了适配器模式，是怎么回事呢？当时开发时明确的指明：人员信息简管理的对象是所有员工的所有信息，然后我们就这样设计了一个类图：
还是比较简单的，有一个对象 UserInfo 存储用户的所有信息（实际系统上还有很多子类，不多说了），也就是 BO（Business Object），这个对象设计为贫血对象（Thin Business Object），不需要存储状态以及相关的关系，而且我也是反对使用充血对象（Rich Business Object），这里说了两个名词贫血对象和充血对象，这两个名词很简单，在领域模型中分别叫做贫血领域模型和充血领域模型，有什么区别呢？在一个对象中不存储实体状态以及对象之间的关系的就叫做贫血对象，上升到领域模型中就是贫血领域模型，有实体状态和对象关系的模型的就是充血领域模型，是不是太技术化了？这个看不懂没关系，都是糊弄人的东西，属于专用名词，这本书写完了，我再折腾本领域模型的文章，揭露领域模型中糊弄人的专有名词，这个绝对是专有名词的堆砌，呵呵。扯远了，我们继续说适配器模式，这个 UserInfo 对象，在系统中很多地方使用，你可以查看自己的信息，也可以做修改，当然这个对象是有 setter 方法的，我们这里用不到就隐藏掉了。
人力资源公司有一套自己的人员管理系统，我们公司需要把我们使用到的人员信息传输到我们的系统中，系统之间的传输使用 RMI（Remote Method Invocation，远程对象调用）的方式，但是有一个问题人力资源公司的人员对象和我们系统的对象不相同呀，他们的对象是这样的：
人员资源公司是把人的信息分为了三部分：基本信息，办公信息和个人家庭信息，并且都放到了 HashMap 中，比如人员的姓名放到 BaseInfo 信息中，家庭地址放到 HomeInfo 中，这咱不好说他们系统设计的不好，那问题是咱的系统要和他们系统有交互，怎么办？使用适配器模式，类图如下：
大家可能会问，这两个对象都不在一个系统中，你如何使用呢？简单！RMI 已经帮我们做了这件事情，只要有接口，就可以把远程的对象当成本地的对象使用，这个大家有时间可以去看一下 RMI 文档，不多说了。通过适配器，把 OuterUser 伪装成我们系统中一个 IUserInfo 对象，这样，我们的系统基本不用修改什么程序员，所有的人员查询、调用跟本地一样样的，说的口干舌燥，那下边我们来看具体的代码实现：
首先看 IUserInfo.java 的代码：
package com.cbf4life; /** *用户信息对象 */ public interface IUserInfo { //获得用户姓名 public String getUserName(); //获得家庭地址 public String getHomeAddress(); //手机号码，这个太重要，手机泛滥呀 public String getMobileNumber(); //办公电话，一般式座机 public String getOfficeTelNumber(); //这个人的职位是啥 public String getJobPosition(); //获得家庭电话，这个有点缺德，我是不喜欢打家庭电话讨论工作 public String getHomeTelNumber(); }然后看这个接口的实现类：
package com.cbf4life; public class UserInfo implements IUserInfo { /* *获得家庭地址，下属送礼也可以找到地方 */ public String getHomeAddress() { System.out.println("这里是员工的家庭地址...."); return null; } /* *获得家庭电话号码 */ public String getHomeTelNumber() { System.out.println("员工的家庭电话是...."); return null; } /* *员工的职位，是部门经理还是小兵 */ public String getJobPosition() { System.out.println("这个人的职位是BOSS...."); return null; } /* *手机号码 */ public String getMobileNumber() { System.out.println("这个人的手机号码是0000...."); return null; } /* *办公室电话，烦躁的时候最好“不小心”把电话线踢掉，我经常这么干，对己对人都有好处 */ public String getOfficeTelNumber() { System.out.println("办公室电话是...."); return null; } /* *姓名了，这个老重要了 */ public String getUserName() { System.out.println("姓名叫做..."); return null; } }可能有人要问了，为什么要把电话号码、手机号码都设置成 String 类型，而不是 int 类型，大家觉的呢？题外话，这个绝对应该是 String 类型，包括数据库也应该是 varchar 类型的，手机号码有小灵通带区号的，比如 02100001，这个你用数字怎么表示？有些人要在手机号码前加上 0086 后再保存，比如我们公司的印度阿三就是这样，喜欢在手机号码前 0086 保存下来，呵呵，我是想到啥就说啥，啰嗦了点。继续看我们的代码，下面看我们系统的应用如何调用 UserInfo 的信息：
package com.cbf4life; /** *这就是我们具体的应用了，比如老板要查所有的20-30的女性信息 */ public class App { public static void main(String[] args) { //没有与外系统连接的时候，是这样写的 IUserInfo youngGirl = new UserInfo(); //从数据库中查到101个 for(int i=0;i<101;i++){ youngGirl.getMobileNumber(); } } }这老板，比较那个，为什么是 101，是男生都应该知道吧，111 代表男生，101 代表女生，呵呵，是不是比较色呀。从数据库中生成了 101 个 UserInfo 对象，直接打印出来就成了。那然后增加了外系统的人员信息，怎么处理呢？下面是 IOuterUser.java 的源代码：
public interface IOuterUser { //基本信息，比如名称，性别，手机号码了等 public Map getUserBaseInfo(); //工作区域信息 public Map getUserOfficeInfo(); /用户的家庭信息 public Map getUserHomeInfo(); }我们再看看外系统的用户信息的具体实现类：
package com.cbf4life; import java.util.HashMap; import java.util.Map; /** *外系统的用户信息的实现类 */ @SuppressWarnings("all") public class OuterUser implements IOuterUser { /* *用户的基本信息 */ public Map getUserBaseInfo() { HashMap baseInfoMap = new HashMap(); baseInfoMap.put("userName", "这个员工叫混世魔王...."); baseInfoMap.put("mobileNumber", "这个员工电话是...."); return baseInfoMap; } /* *员工的家庭信息 */ public Map getUserHomeInfo() { HashMap homeInfo = new HashMap(); homeInfo.put("homeTelNumbner", "员工的家庭电话是...."); homeInfo.put("homeAddress", "员工的家庭地址是...."); return homeInfo; } /* *员工的工作信息，比如职位了等 */ public Map getUserOfficeInfo() { HashMap officeInfo = new HashMap(); officeInfo.put("jobPosition","这个人的职位是BOSS..."); officeInfo.put("officeTelNumber", "员工的办公电话是...."); return officeInfo; } }那怎么把外系统的用户信息包装成我们公司的人员信息呢？看下面的 OuterUserInfo 类源码，也就是我们的适配器：
package com.cbf4life; import java.util.Map; /** *把OuterUser包装成UserInfo */ @SuppressWarnings("all") public class OuterUserInfo extends OuterUser implements IUserInfo { private Map baseInfo = super.getUserBaseInfo(); //员工的基本信息 private Map homeInfo = super.getUserHomeInfo(); //员工的家庭 信息 private Map officeInfo = super.getUserOfficeInfo(); //工作信息 /* *家庭地址 */ public String getHomeAddress() { String homeAddress = (String)this.homeInfo.get("homeAddress"); System.out.println(homeAddress); return homeAddress; } /* *家庭电话号码 */ public String getHomeTelNumber() { String homeTelNumber = (String)this.homeInfo.get("homeTelNumber"); System.out.println(homeTelNumber); return homeTelNumber; } /* *职位信息 */ public String getJobPosition() { String jobPosition = (String)this.officeInfo.get("jobPosition"); System.out.println(jobPosition); return jobPosition; } /* *手机号码 */ public String getMobileNumber() { String mobileNumber = (String)this.baseInfo.get("mobileNumber"); System.out.println(mobileNumber); return mobileNumber; } /* *办公电话 */ public String getOfficeTelNumber() { String officeTelNumber = (String)this.officeInfo.get("officeTelNumber"); System.out.println(officeTelNumber); return officeTelNumber; } /* *员工的名称 */ public String getUserName() { String userName = (String)this.baseInfo.get("userName"); System.out.println(userName); return userName; } }大家看到没？这里有很多的强制类型转换，就是(String)这个东西，如果使用泛型的话，完全就可以 避免这个转化，这节课啰嗦的太多就不再讲了，下次找个时间再讲。这个适配器的作用就是做接口的转换，那然后我们再来看看我们的业务是怎么调用的：
package com.cbf4life; /** *这就是我们具体的应用了，比如老板要查所有的20-30的女性信息 */ public class App { public static void main(String[] args) { //没有与外系统连接的时候，是这样写的 //IUserInfo youngGirl = new UserInfo(); //老板一想不对呀，兔子不吃窝边草，还是找人力资源的员工好点 IUserInfo youngGirl = new OuterUserInfo(); //我们只修改了这一句好 //从数据库中查到101个 for(int i=0;i<101;i++){ youngGirl.getMobileNumber(); } } }大家看，使用了适配器模式只修改了一句话，其他的业务逻辑都不用修改就解决了系统对接的问题，而且在我们实际系统中只是增加了一个业务类的继承，就实现了可以查本公司的员工信息，也可以查人力资源公司的员工信息，尽量少的修改，通过扩展的方式解决了该问题适配器模式分为类适配器和对象适配器，这个区别不大，上边的例子就是类适配器，那对象适配器是什么样子呢？对象适配器的类图是这个样子滴：看到没？和上边的类图就一个箭头的图形的差异，一个是继承，一个是关联，就这么多区别，只要把我们上面的程序稍微修改一下就成了类适配器，这个大家自己考虑一下，简单的很。适配器模式不适合在系统设计阶段采用，没有一个系统分析师会在做详设的时候考虑使用适配器模式，这个模式使用的主要场景是扩展应用中，就像我们上面的那个例子一样，系统扩展了，不符合原有设计的时候才考虑通过适配器模式减少代码修改带来的风险。在论坛上有网友建议我加上模式的优缺点，这个我是不建议加上去，你先掌握了怎么使用，然后再想怎么更好的使用，而且我想你既然想到了你要使用这 23 个模式，肯定是有权衡的吧，那这个模式的优缺点是不是由你自己来总结会更好的呢？
