1700479762
设计模式之禅 [:1700454076]
1700479763
设计模式之禅 33.2 门面模式VS中介者模式
1700479764
1700479765
门面模式为复杂的子系统提供一个统一的访问界面，它定义的是一个高层接口，该接口使得子系统更加容易使用，避免外部模块深入到子系统内部而产生与子系统内部细节耦合的问题。中介者模式使用一个中介对象来封装一系列同事对象的交互行为，它使各对象之间不再显式地引用，从而使其耦合松散，建立一个可扩展的应用架构。
1700479766
1700479767
33.2.1 中介者模式实现工资计算
1700479768
1700479769
大家工作会得到工资，那么工资与哪些因素有关呢？这里假设工资与职位、税收有关，职位提升工资就会增加，同时税收也增加，职位下降了工资也同步降低，当然税收也降低。而如果税收比率增加了呢？工资自然就减少了！这三者之间两两都有关系，很适合中介者模式的场景，类图如图33-4所示。
1700479770
1700479771
1700479772
1700479773
1700479774
图33-4 工资、职位、税收的示意类图
1700479775
1700479776
类图中的方法比较简单，我们主要分析的是三者之间的关系，通过类图可以发现三者之间已经没有耦合，原本在需求分析时我们发现三者有直接的交互，采用中介者模式后，三个对象之间已经相互独立了，全部委托中介者完成。我们在类图中还定义了一个抽象同事类，它是一个标志性接口，其子类都是同事类，都可以被中介者接收，如代码清单33-11所示。
1700479777
1700479778
代码清单33-11 抽象同事类
1700479779
1700479780
public abstract class AbsColleague{
1700479781
1700479782
//每个同事类都对中介者非常了解
1700479783
1700479784
protected AbsMediator mediator；
1700479785
1700479786
public AbsColleague（AbsMediator_mediator）{
1700479787
1700479788
this.mediator=_mediator；
1700479789
1700479790
}
1700479791
1700479792
}
1700479793
1700479794
在抽象同事类中定义了每个同事类对中介者都非常了解，如此才能把请求委托给中介者完成。三个同事类都具有相同的设计，即定义一个业务接口以及每个对象必须实现的职责，同时既然是同事类就都继承AbsColleague。抽象同事类只是一个标志性父类，并没有限制子类的业务逻辑，因此每一个同事类并没有违背单一职责原则。首先来看职位接口，如代码清单33-12所示。
1700479795
1700479796
代码清单33-12 职位接口
1700479797
1700479798
public interface IPosition{
1700479799
1700479800
//升职
1700479801
1700479802
public void promote（）；
1700479803
1700479804
//降职
1700479805
1700479806
public void demote（）；
1700479807
1700479808
}
1700479809
1700479810
职位会有升有降，职位变化如代码清单33-13所示。
1700479811