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
1700479812
代码清单33-13职位
1700479813
1700479814
public class Position extends AbsColleague implements IPosition{
1700479815
1700479816
public Position（AbsMediator_mediator）{
1700479817
1700479818
super（_mediator）；
1700479819
1700479820
}
1700479821
1700479822
public void demote（）{
1700479823
1700479824
super.mediator.down（this）；
1700479825
1700479826
}
1700479827
1700479828
public void promote（）{
1700479829
1700479830
super.mediator.up（this）；
1700479831
1700479832
}
1700479833
1700479834
}
1700479835
1700479836
每一个职位的升降动作都委托给中介者执行，具体一个职位升降影响到谁这里没有定义，完全由中介者完成，简单而且扩展性非常好。下面我们来看工资接口，如代码清单33-14所示。
1700479837
1700479838
代码清单33-14 工资接口
1700479839
1700479840
public interface ISalary{
[
上一页 ]
[ :1.700479791e+09 ]
[
下一页 ]