组员向仲裁者报告，仲裁者向组员下达指示。

Mediator：仲裁者、中介者。

中介模式的设计思想跟中间层很像，通过引入中介这个中间层，将一组对象之间的交互关系（或者说依赖关系）从多对多（网状关系）转换为一对多（星状关系）。原来一个对象要跟 n 个对象交互，现在只需要跟一个中介对象交互，从而最小化对象之间的交互关系，降低了代码的复杂度，提高了代码的可读性和可维护性。

仲裁者通过使用 Colleague 的 controlColleague 进行控制。如果需要更换不同的仲裁策略，可以使用 Strategy 模式。

登场角色：

• Mediator（仲裁者、中介者）：Mediator 角色负责定义与 Colleague 角色进行通信和做出决定的接口（API）。
• ConcreteMediator（具体的仲裁者、中介者）：ConcreteMediator 角色负责实现 Mediator 角色的接口（API），负责实际做出决定。
• Colleague（同事）：Colleague 角色负责定义与 Mediator 角色进行通信的接口（API）。
• ConcreteColleague（具体的同事）：ConcreteColleague 角色负责实现 Colleague 角色的接口（API）。

通常情况下，面向对象编程可以帮助我们分散处理，避免处理过于集中（分而治之）。但是在某些情况下，应当集中处理的部分需要集中起来。

使用中介模式后，原本业务逻辑会分散在各个控件中，现在都集中到了中介类中。实际上，这样做既有好处，也有坏处。好处是简化了控件之间的交互，坏处是中介类有可能会变成大而复杂的上帝类（God Class）。所以，在使用中介模式的时候，我们要根据实际的情况，平衡对象之间交互的复杂度和中介类本身的复杂度。

相关设计模式

在中介者模式中，Mediator 角色与 Colleague 角色进行交互。而在 站内文章门面模式 中，Facade 角色单方面地使用其他角色来对外提供高层接口（API）。因此，可以说 Mediator 模式是双向的，而 Facade 模式是单向的。

中介者模式与观察者模式

中介者模式和 站内文章观察者模式 之间的区别往往很难记住。在大部分情况下，可以使用其中一种模式，而有时可以同时使用。

观察者模式有多种实现方式。虽然经典的实现方式没法彻底解耦观察者和被观察者，观察者需要注册到被观察者中，被观察者状态更新需要调用观察者的 update() 方法。但是，在跨进程的实现方式中，我们可以利用消息队列实现彻底解耦，观察者和被观察者都只需要跟消息队列交互，观察者完全不知道被观察者的存在，被观察者也完全不知道观察者的存在。

中介模式也是为了解耦对象之间的交互，所有的参与者都只与中介进行交互。而观察者模式中的消息队列，就有点类似中介模式中的「中介」，观察者模式的中观察者和被观察者，就有点类似中介模式中的「参与者」。

有时中介模式就是使用了观察者模式来实现 Mediator 角色与 Colleague 角色之间的通信。中介者对象担当发布者的角色，其他组件则作为订阅者，可以订阅中介者的事件或取消订阅。当中介者以这种方式实现时， 它可能看上去与观察者非常相似。

在观察者模式中，尽管一个参与者既可以是观察者，同时也可以是被观察者，但是，大部分情况下，交互关系往往都是单向的，一个参与者要么是观察者，要么是被观察者，不会兼具两种身份。也就是说，在观察者模式的应用场景中，参与者之间的交互关系比较有条理。

而中介模式正好相反。只有当参与者之间的交互关系错综复杂，维护成本很高的时候，我们才考虑使用中介模式。如果一个参与者状态的改变，其他参与者执行的操作有一定先后顺序的要求，这个时候，中介模式就可以利用中介类，通过先后调用不同参与者的方法，来实现顺序的控制，而观察者模式是无法实现这样的顺序要求的。

本文参考

• 《图解设计模式》16 章
• 本科生课程笔记《程序设计中级实践＆设计模式》 - TJU 🍐⚱️
• 极客时间专栏 - 设计模式之美 - 王争
• 中介者设计模式