1700480062
代码清单33-20 场景类
1700480063
1700480064
public class Client{
1700480065
1700480066
public static void main（String[]args）{
1700480067
1700480068
//定义中介者
1700480069
1700480070
Mediator mediator=new Mediator（）；
1700480071
1700480072
//定义各个同事类
1700480073
1700480074
IPosition position=new Position（mediator）；
1700480075
1700480076
ISalary salary=new Salary（mediator）；
1700480077
1700480078
ITax tax=new Tax（mediator）；
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
