适配器模式，是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。
适配器模式-主图镇楼
公司的发展速度很快，一不小心，就收购了一个创业团队去做细分市场。这么一个改变，对于公司来说，是一个进步，但是对于正在开发和维护公司内部员工系统的小蔡来说，却是一个不大不小的麻烦。
小蔡跑来找老王，说：“老王，你知道我们公司收购了一个小团队不？”
老王说：“知道啊，咋了？”
小蔡又问：“那你知道咋们公司的员工系统是有我再维护的不？”
老王又说：“知道啊，咋了？”
不明真相的老王
小蔡说：“我们公司的员工系统里对员工的定义，和他们团队的员工系统对员工的定义，不太一样啊。现在张经理让我在我们的系统里去集成他们的系统，我有个想法，你帮我看看对不对，好吗？”
//公司员工类
public class CompanyEmployee{
//主键ID
public int id;
//用户名
public String username;
//联系方式
public String mobile;
}
//查询员工的Dao类
public class EmployeeDao {
//根据员工ID获取员工对象
public CompanyEmployee getEmployeeById(int id){
//从数据库查询一个员工后返回
return findEmployeeById(id);
}
}
小蔡接着说：“你看，上面是我们系统现在的情况，但是创业团队他们那边的代码是下面这个样子。”
//创业团队的员工类
public class GroupEmployee {
//主键ID
public long id;
//用户名
public String email;
//联系方式
public String phone;
}
//查询员工的Dao类
public class EmployeeDao {
//根据员工ID获取员工对象
public GroupEmployee getEmployeeById(int id){
//从数据库查询一个员工后返回
return findEmployeeById(id);
}
}
小蔡接着说：“我们的员工类不一样，查询的方法也不一样，查询出来的结果也不一样，难道要我把所有增删改查重新写一遍吗？难道要我再使用员工对象的地方也多写一堆方法，来兼容不同的参数类型么?”
老王微微一笑，说：“你想多了。其实一个适配器模式就可以解决你的问题。”
老王的迷之微笑
小蔡好奇的问：“适配器是什么？”
老王说：“适配器，你的Mac Book上，电源线上那一大坨白色的圆角矩形，就是适配器，他让你不论接入220V电压，还是360V电压，你的Mac Book都可以正常充电。简单说，适配器就是不论接受的输入是什么，它的输出总是一定的。”
小蔡的适配器
小蔡说：“听上去，挺不错的，那我该怎么做呢？”
老王说：“睁大眼睛看好咯。下面我要写适配器了。”
//员工适配器
public class EmployeeAdapter {
public static CompanyEmployee getEmployee(GroupEmployee employee){
CompanyEmployee companyEmployee = new CompanyEmployee();
companyEmployee.id = (int) employee.id;
companyEmployee.username = employee.email;
companyEmployee.mobile = employee.phone;
return companyEmployee;
}
}
老王接着说：“就这样就行了。这样你就可以将他们的员工类型转成我们的员工类型了。如果将来还有其他的员工类型，我们再适配器里增加一个方法，转一下就行了。这样我们不用起重写增删改查了。”
小蔡眨了眨眼镜说：“老王，没对啊他们的员工id是long型的”
老王说：“那是他们疯了，一个员工系统的id怎么可能设计为long型？那得有多少员工啊?”
小蔡接着问：“感觉好像太简单了吧？真这么简单？”
老王说：“小蔡，设计模式是一种理念，并不是固定格式的代码。当然，经历过很多年的实践和总结后，的确有一套大家认为最合理的实践规范。但是我们要记住，设计模式只是经验的总结，只是一种理念，并不是固定格式，适配器模式的精髓在于，面对不同的输入，我们总是能得到固定的输出。这就足够了。要敢于质疑权威和经验，这样才能有思考和进步。对于目前我们的情况来说，我觉得这样的代码已经足够了。”
老王/小蔡求打赏
更多内容，正在赶来，敬请关注“小蔡和老王的技术日常”。
PS：小蔡和老王的技术日常，已经建立QQ群，欢迎各位小伙伴通过发送简信的方式联系我们，询问QQ号。
网友评论