-
中介者抽象类（即调用方）
- 一系列客户实现类的属性：统一在抽象类里定义好所有中介者需要的客户实现类（因为每个客户实现类有自己独特的业务方法，所以必须依赖客户实现类）
- 每个客户实现类的getter和setter（因为客户实现类并不是每个场景都是必须的，所以不用通过构造方法传入依赖）
- abstract execute方法：定义业务逻辑，调用各个客户的关系
-
中介者类 extends 中介者抽象类 （某些业务场景需要定义多个不同的中介角色，所以把公用逻辑提取到抽象类里）
- override execute方法：定义业务逻辑，调用各个客户的业务逻辑代码
-
客户抽象类 （被调用方）
- mediator属性：中介者抽象类
- constructor(中介者抽象类）
-
客户实现类 extends 客户抽象类
- constructor: 定义同父类抽象类一样带有中介者抽象类参数，根据不同场景，传入对应的中介者实现类。
- 自己所属职能的业务方法
- 涉及到综合业务的方法，且是从这个客户角色触发的，调用super.mediator.execute，交给中介者去协调处理。
总结：
关系：
- 中介者的抽象类和客户的抽象类，各自定义了对方的属性，相互依赖调用对方。
- 客户的实现类在业务场景中对应不同的业务职能角色，他们有所属自己专门的业务逻辑方法，一般一个方法对应一种业务场景，一个客户类包含了所有业务场景的方法。
- 一般一个中介者的实现类对应一种业务场景，定义了这个场景下如何协调串联起各个客户各自对应这个场景的业务逻辑方法。
- 所有的业务场景都是从客户类驱动触发，外部类是感知不到中介者的，由客户方自己的入口方法委托给对应的中介者实现去做这个业务场景。
- 所有的交互耦合集中在中介者这一点，适用于网状关系（多对多）的多个客户类场景。
缺点：
中介者的协同客户逻辑可能会变得复杂庞大，注意控制粒度。
