公司的发展速度很快,一不小心,就收购了一个创业团队去做细分市场。这么一个改变,对于公司来说,是一个进步,但是对于正在开发和维护公司内部员工系统的小蔡来说,却是一个不大不小的麻烦。
小蔡跑来找老王,说:"老王,你知道我们公司收购了一个小团队不?"
老王说:"知道啊,咋了?"
小蔡又问:"那你知道咋们公司的员工系统是有我再维护的不?"
老王又说:"知道啊,咋了?"
小蔡说:"我们公司的员工系统里对员工的定义,和他们团队的员工系统对员工的定义,不太一样啊。现在张经理让我在我们的系统里去集成他们的系统,我有个想法,你帮我看看对不对,好吗?"
- //公司员工类
- 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 型?那得有多少员工啊?"
小蔡接着问:"感觉好像太简单了吧?真这么简单?"
老王说:"小蔡,设计模式是一种理念,并不是固定格式的代码。当然,经历过很多年的实践和总结后,的确有一套大家认为最合理的实践规范。但是我们要记住,设计模式只是经验的总结,只是一种理念,并不是固定格式,适配器模式的精髓在于,面对不同的输入,我们总是能得到固定的输出。这就足够了。要敢于质疑权威和经验,这样才能有思考和进步。对于目前我们的情况来说,我觉得这样的代码已经足够了。"
来源: http://www.cnblogs.com/wisekingokok/p/6547163.html