1700480079
1700480080
//职位提升了
1700480081
1700480082
System.out.println（”===职位提升===”）；
1700480083
1700480084
position.promote（）；
1700480085
1700480086
}
1700480087
1700480088
}
1700480089
1700480090
运行结果如下所示：
1700480091
1700480092
===职位提升===
1700480093
1700480094
职位上升一级，狂喜
1700480095
1700480096
工资翻倍，乐翻天
1700480097
1700480098
税收上升，为国家做贡献
1700480099
1700480100
我们回过头来分析一下设计，在接收到需求后我们发现职位、工资、税收之间有着紧密的耦合关系，如果不采用中介者模式，则每个对象都要与其他两个对象进行通信，这势必会增加系统的复杂性，同时也使系统处于僵化状态，很难实现拥抱变化的理想。通过增加一个中介者，每个同事类的职位、工资、税收都只与中介者通信，中介者封装了各个同事类之间的逻辑关系，方便系统的扩展和维护。
1700480101
1700480102
1700480103
1700480104
1700480105
设计模式之禅 33.2.2 门面模式实现工资计算
1700480106
1700480107
工资计算是一件非常复杂的事情，简单地来说，它是对基本工资、月奖金、岗位津贴、绩效、考勤、税收、福利等因素综合运算后的一个数字。即使设计一个HR（人力资源）系统，员工工资计算也是非常复杂的模块，但是对于外界，比如高管层，最希望看到的结果是张三拿了多少钱，李四拿了多少钱，而不是看中间的计算过程，怎么计算那是人事部门的事情。换句话说，对外界的访问者来说，它只要传递进去一个人员名称和月份即可获得工资数，而不用关心其中的计算有多么复杂，这就用得上门面模式了。
1700480108
1700480109
门面模式对子系统起封装作用，它可以提供一个统一的对外服务接口，如图33-5所示。
1700480110
1700480111
1700480112
1700480113
1700480114
图33-5 HR系统的类图
1700480115
1700480116
该类图主要实现了工资计算，通过HRFacade门面可以查询用户的工资以及出勤天数等，而不用关心这个工资或者出勤天数是怎么计算出来的，从而屏蔽了外系统对工资计算模块的内部细节依赖。我们先看子系统内部的各个实现，考勤情况如代码清单33-21所示。
1700480117
1700480118
代码清单33-21 考勤情况
1700480119
1700480120
public class Attendance{
1700480121
1700480122
//得到出勤天数
1700480123
1700480124
public int getWorkDays（）{
1700480125
1700480126
return（new Random（））.nextInt（30）；
1700480127
1700480128
}