1700471784
liSi.setSalary（1900）；
1700471785
1700471786
liSi.setSex（Employee.FEMALE）；
1700471787
1700471788
empList.add（liSi）；
1700471789
1700471790
//再产生一个经理
1700471791
1700471792
Manager wangWu=new Manager（）；
1700471793
1700471794
wangWu.setName（“王五”）；
1700471795
1700471796
wangWu.setPerformance（“基本上是负值，但是我会拍马屁呀”）；
1700471797
1700471798
wangWu.setSalary（18750）；
1700471799
1700471800
wangWu.setSex（Employee.MALE）；
1700471801
1700471802
empList.add（wangWu）；
1700471803
1700471804
return empList；
1700471805
1700471806
}
1700471807
1700471808
}
1700471809
1700471810
先通过mockEmployee来模拟出一个数组，初始化两个员工和一个经理，当然在实际项目中这个数组应该由持久层产生。运行结果如下所示：
1700471811
1700471812
姓名：张三 性别：男 薪水：1800 工作：编写Java程序，绝对的蓝领、苦工加搬运工
1700471813
1700471814
姓名：李四 性别：女 薪水：1900 工作：页面美工，审美素质太不流行了！
1700471815
1700471816
姓名：王五 性别：男 薪水：18750 业绩：基本上是负值，但是我会拍马屁呀
1700471817
1700471818
结果出来了，非常正确。我们来想一想实际的情况，人力资源部门拿这份表格会给谁看呢？那当然是大老板了！大老板关心的是什么？关心部门经理的业绩！小兵的情况不是他要了解的，就像二战的时候一位将军说：“我一想到我的士兵也有孩子、妻子、父母，我就痛心疾首……但是这是战场，我只能认为他们是一群机器……”是啊，其实我们也一样啊，那问题就出来了：
1700471819
1700471820
❑大老板就看部门经理的报表，小兵的报表可看可不看。
1700471821
1700471822
❑多个大老板的“嗜好”是不同的，主管销售的，则主要关心营销的情况；主管会计的，则主要关心企业的整体财务运行状态；主管技术的，则主要看技术的研发情况。
1700471823
1700471824
综合成一句话，这个报表会修改：数据的修改以及报表的展现修改，按照开闭原则，项目分析的时候已经考虑到这些可能引起变更的因素，就需要在设计时考虑通过扩展来避开未来需求变更而引起的代码修改风险。我们来想一想，每个普通员工类和经理类都用一个方法report（从父类继承过来的），他无法为每一个子类定制特殊的属性，简化类图如图25-2所示。
1700471825
1700471826
1700471827
1700471828
1700471829
图25-2 简化类图
1700471830
1700471831
我们思考一下，如何提供一个能够为每个子类定制报表的方法呢？可以这样思考，普通员工和管理层员工是两个不同的对象，例如，我邀请一个人过来参观我的家，参观者参观完毕后分别进行描述，那参观的对象不同，描述的结果也当然不同。好，按照这思路，我们把方法report提取到另外一个类Visitor中来实现，如图25-3所示。
1700471832
1700471833
