1700466021
1700466022
public String getMobileNumber（）{
1700466023
1700466024
System.out.println（“这个人的手机号码是0000……”）；
1700466025
1700466026
return null；
1700466027
1700466028
}
1700466029
1700466030
/*
1700466031
1700466032
*办公室电话，烦躁的时候最好”不小心”把电话线踢掉
1700466033
1700466034
*/
1700466035
1700466036
public String getOfficeTelNumber（）{
1700466037
1700466038
System.out.println（“办公室电话是……”）；
1700466039
1700466040
return null；
1700466041
1700466042
}
1700466043
1700466044
/*
1700466045
1700466046
*姓名，这个很重要
1700466047
1700466048
*/
1700466049
1700466050
public String getUserName（）{
1700466051
1700466052
System.out.println（“姓名叫做……”）；
1700466053
1700466054
return null；
1700466055
1700466056
}
1700466057
1700466058
}
1700466059
1700466060
这个项目是2004年年底投产的，运行到2005年年底还是比较平稳的，中间修修补补也很正常，2005年年底不知道是哪股风吹的，很多公司开始使用借聘人员的方式引进人员，我们公司也不例外，从一个劳动资源公司借用了一大批的低技术、低工资的人员，分配到各个子公司，总共有将近200人，然后人力资源部就找我们部门老大谈判，说要增加一个功能：借用人员管理，老大一看有钱赚呀，一拍大腿，做！
1700466061
1700466062
老大命令一下来，我立马带人过去调研，需求就一句话，但是真深入地调研还真不是那么简单。借聘人员虽然在我们公司干活，和我们一个样，干活时没有任何的差别，但是他们的人员信息、工资情况、福利情况等都是由劳动服务公司管理的，并且有一套自己的人员管理系统，人力资源部门就要求我们系统同步劳动服务公司的信息，当然是只要在我们公司工作的人员信息，其他人员信息是不需要的，而且还要求信息同步，也就是：劳动服务公司的人员信息一变更，我们系统就应该立刻体现出来，为什么要即时而不批量呢？是因为我们公司与劳动服务公司之间是按照人头收费的，甭管是什么人，只要我们公司借用，就这个价格，你要一个研究生，你派了一个高中生给我，那算什么事？因此，了解了业务需求用后，项目组决定采用RMI（Remote Method Invocation，远程对象调用）的方式进行联机交互，但是深入分析后，一个重大问题立刻显现出来：劳动服务公司的人员对象和我们系统的对象不相同，他们的对象如下所示。
1700466063
1700466064
1700466065
1700466066
1700466067
图19-2 劳动服务公司的人员信息类图
1700466068
1700466069
劳动服务公司是把人员信息分为了三部分：基本信息、办公信息和个人家庭信息，并且都放到了HashMap中，比如人员的姓名放到BaseInfo信息中，家庭地址放到HomeInfo中，这也是一个可以接受的模式，我们来看看他们的代码，接口如代码清单19-3所示。
1700466070