设计模式——适配器模式【Adapter Pattern】

今天讲适配器模式，这个模式也很简单，你笔记本上的那个拖在外面的黑盒子就是个适配器，一般你在中国能用，在日本也能用，虽然两个国家的的电源电压不同，中国是220V，日本是110V，但是这个适配器能够把这些不同的电压转换为你需要的36V电压，保证你的笔记本能够正常运行，那我们在设计模式中引入这个适配器模式是不是也是这个意思呢？是的，一样的作用，两个不同接口，有不同的实现，但是某一天突然上帝命令你把B接口转换为A接口，怎么办？继承，能解决，但是比较傻，而且还违背了OCP原则，怎么办？好在我们还有适配器模式。

做一个人力资源管理，该项目是我们总公司发起的项目，公司一共有700多号人，包括子公司，这个项目还是比较简单的，分为三大模块：人员信息管理，薪酬管理，职位管理，其中人员管理这块就用到了适配器模式，是怎么回事呢？当时开发时明确的指明：人员信息简管理的对象是所有员工的所有信息，然后我们就这样设计了一个类图：

还是比较简单的，有一个对象UserInfo存储用户的所有信息。这个UserInfo对象，在系统中很多地方使用，你可以查看自己的信息，也可以做修改，当然这个对象是有setter方法的，我们这里用不到就隐藏掉了。 不知道是那股风吹的，很多公司开始使用借聘人员的方式招聘人员，我们公司也不例外，从一个人力资源公司借用了一大批的低技术、低工资的人员，分配到各个子公司。人力资源公司有一套自己的人员管理系统，我们公司需要把我们使用到的人员信息传输到我们的系统中，系统之间的传输使用RMI（Remote Method Invocation，远程对象调用）的方式，但是有一个问题人力资源公司的人员对象和我们系统的对象不相同呀，他们的对象是这样的：

人员资源公司是把人的信息分为了三部分：基本信息，办公信息和个人家庭信息，并且都放到了HashMap中，比如人员的姓名放到BaseInfo信息中，家庭地址放到HomeInfo中，这咱不好说他们系统设计的不好，那问题是咱的系统要和他们系统有交互，怎么办？使用适配器模式，类图如下：

 

大家可能会问，这两个对象都不在一个系统中，你如何使用呢？简单！RMI已经帮我们做了这件事情，只要有接口，就可以把远程的对象当成本地的对象使用，这个大家有时间可以去看一下RMI文档，不多说了。通过适配器，把OuterUser伪装成我们系统中一个IUserInfo对象，这样，我们的系统基本不用修改什么程序员，所有的人员查询、调用跟本地一样样的，说的口干舌燥，那下边我们来看具体的代码实现：

首先看IUserInfo.java的代码：

 

package adapter.pattern; /** * 用户信息对象 */ public interface IUserInfo { //获得用户姓名 public String getUserName(); //获得家庭地址 public String getHomeAddress(); //手机号码，这个太重要，手机泛滥呀 public String getMobileNumber(); //办公电话，一般式座机 public String getOfficeTelNumber(); //这个人的职位是啥 public String getJobPosition(); //获得家庭电话，这个有点缺德，我是不喜欢打家庭电话讨论工作 public String getHomeTelNumber(); }

然后看这个接口的实现类：

 

package adapter.pattern; /** * 的实现类 */ 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 adapter.pattern; /** * 这就是我们具体的应用了，比如老板要查所有的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的源代码：

 package adapter.pattern; import java.util.Map; /** * 外系统的人员信息 */ @SuppressWarnings("all") public interface IOuterUser { //基本信息，比如名称，性别，手机号码了等 public Map getUserBaseInfo(); //工作区域信息 public Map getUserOfficeInfo(); //用户的家庭信息 public Map getUserHomeInfo(); }

我们再看看外系统的用户信息的具体实现类：

package adapter.pattern; 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 adapter.pattern; 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 adapter.pattern; /** * 这就是我们具体的应用了，比如老板要查所有的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(); } } }

大家看，使用了适配器模式只修改了一句话，其他的业务逻辑都不用修改就解决了系统对接的问题，而且在我们实际系统中只是增加了一个业务类的继承，就实现了可以查本公司的员工信息，也可以查人力资源公司的员工信息，尽量少的修改，通过扩展的方式解决了该问题。适配器模式分为类适配器和对象适配器，这个区别不大，上边的例子就是类适配器，那对象适配器是什么样子呢？对象适配器的类图是这个样子滴：

 

看到没？和上边的类图就一个箭头的图形的差异，一个是继承，一个是关联，就这么多区别，只要把我们上面的程序稍微修改一下就成了类适配器，这个大家自己考虑一下，简单的很。 适配器模式不适合在系统设计阶段采用，没有一个系统分析师会在做详设的时候考虑使用适配器模式，这个模式使用的主要场景是扩展应用中，就像我们上面的那个例子一样，系统扩展了，不符合原有设计的时候才考虑通过适配器模式减少代码修改带来的风险。