中介者设计模式

意图

• 定义一个对象，该对象封装一组对象如何交互。Mediator 通过阻止对象显式地相互引用来促进松散耦合，并且它允许您独立地改变它们的交互。
• 设计一个中介来解耦许多对等点。
• 将交互对等点之间的多对多关系提升为“完整对象状态”。

问题

我们想要设计可重用的组件，但潜在可重用部分之间的依赖关系展示了“意大利面条代码”现象（试图舀一个服务会导致“全有或全无”）。

讨论

在 Unix 中，访问系统资源的权限在三个粒度级别进行管理：世界、组和所有者。组是旨在对某些功能从属关系建模的用户集合。系统上的每个用户都可以是一个或多个组的成员，并且每个组可以有零个或多个分配给它的用户。下图显示了分配给所有三个组的三个用户。

如果我们要在软件中对此进行建模，我们可以决定将用户对象耦合到组对象，并将组对象耦合到用户对象。然后，当发生更改时，两个类及其所有实例都会受到影响。

另一种方法是引入“额外的间接级别”——将用户映射到组，将组映射到用户，并使其成为自身的抽象。这提供了几个优点：用户和组彼此分离，可以轻松地同时维护和操作许多映射，并且可以通过定义派生类来扩展映射抽象。

将一个系统划分为许多对象通常会增强可重用性，但这些对象之间不断增加的互连往往会再次降低它的可重用性。中介对象：封装所有互连，充当通信枢纽，负责控制和协调其客户端的交互，并通过防止对象显式相互引用来促进松散耦合。

中介者模式将“多对多关系网络”提升为“完整对象状态”。用对象对相互关系建模增强了封装性，并允许通过子类化修改或扩展这些相互关系的行为。

调解器有用的一个例子是操作系统中用户和组功能的设计。一个组可以有零个或多个用户，并且一个用户可以是零个或多个组的成员。中介者模式提供了一种灵活且非侵入性的方式来关联和管理用户和组。

结构

同事（或同行）不相互耦合。每个人都与调解人交谈，调解人反过来知道并指挥其他人的编排。原本会存在的同事之间的“多对多”映射已“提升为完全对象状态”。这种新的抽象提供了一个间接位置，可以在其中托管额外的杠杆作用。

例子

中介者定义了一个控制一组对象如何交互的对象。同事对象之间的松散耦合是通过让同事与中介者而不是彼此进行通信来实现的。受控机场的控制塔很好地展示了这种模式。接近或离开航站楼区域的飞机飞行员与塔台进行通信，而不是明确地相互通信。对谁可以起飞或降落的限制由塔台强制执行。需要注意的是，塔并不控制整个飞行。它的存在只是为了在终端区域强制执行约束。

检查清单

1. 识别将从相互解耦中受益的交互对象的集合。
2. 将这些交互封装在一个新类的抽象中。
3. 创建该新类的实例并重新处理所有“对等”对象以仅与调解器交互。
4. 平衡脱钩原则和责任分配原则。
5. 注意不要创建“控制器”或“上帝”对象。

经验法则

• 责任链、命令、中介者和观察者，解决了如何将发送者和接收者解耦，但需要权衡取舍。责任链沿潜在接收者链传递发送者请求。命令通常指定与子类的发送者-接收者连接。中介者让发送者和接收者间接地相互引用。Observer 定义了一个非常解耦的接口，允许在运行时配置多个接收器。
• Mediator 和 Observer 是相互竞争的模式。它们之间的区别在于，Observer 通过引入“观察者”和“主体”对象来分发通信，而 Mediator 对象封装了其他对象之间的通信。我们发现制作可重用的 Observers 和 Subjects 比制作可重用的 Mediator 更容易。
• 另一方面，Mediator 可以利用 Observer 动态注册同事并与他们通信。
• Mediator 类似于 Facade，因为它抽象了现有类的功能。中介者抽象/集中了同事对象之间的任意通信，它经常“增加价值”，并且被同事对象知道/引用（即它定义了一个多向协议）。相反，Facade 为子系统定义了一个更简单的接口，它不添加新功能，并且子系统类不知道它（即它定义了一个单向协议，它向子系统类发出请求，但反之则不然）。