1700471781
1700471782
liSi.setName（“李四”）；
1700471783
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