中介者模式适合哪些应用场景？
简化版
中介者模式适合多个对象之间交互复杂、依赖关系呈网状、协作规则经常变化的场景。常见例子包括 UI 组件联动、聊天室、工作流协调、模块消息转发和复杂表单控制。
详细版
适合使用中介者模式的典型信号有：
- 对象数量多，互相调用关系复杂；
- 新增一个对象会影响很多已有对象；
- 交互规则比单个对象自身逻辑更复杂；
- 希望把协作规则集中维护。
常见场景：
- UI 表单联动：输入框、按钮、下拉框、提示文案互相影响；
- 聊天室/群组通信：用户之间通过聊天室转发消息；
- 工作流协调：多个步骤、节点、处理器之间需要统一编排；
- 模块解耦：多个模块通过协调器或事件中心通信；
- 机场塔台模型：飞机不互相沟通，由塔台统一调度。
不适合的场景是：对象之间只有简单的一对一调用，或者中介者会把所有业务都集中成一个上帝类。
完整版教学
一、UI 组件联动
UI 是中介者模式最经典的场景之一。
比如一个注册弹窗里有：
- 用户名输入框；
- 密码输入框；
- 验证码输入框；
- 协议勾选框；
- 注册按钮；
- 错误提示区域。
这些组件之间有大量联动：
- 用户名为空，注册按钮禁用；
- 密码强度不足，提示错误；
- 未勾选协议，按钮禁用；
- 验证码输入完成后触发校验；
- 注册成功后关闭弹窗。
如果每个组件都直接控制其他组件，代码会很快变乱。
更好的做法是引入 RegisterDialogMediator，由它统一判断组件状态并更新其他组件。
二、聊天室和消息分发
聊天室例子也很典型。
没有中介者时，用户对象可能要知道其他用户：
UserA -> UserB
UserA -> UserC
UserB -> UserA加入聊天室中介者后：
UserA -> ChatRoom -> UserB/UserC好处是：
- 用户不需要保存其他用户；
- 群发、私聊、禁言等规则集中处理；
- 用户加入或退出时，只影响聊天室的成员管理。
这类场景的共同点是：对象之间不是简单调用，而是需要一个中心协调规则。
三、工作流和流程编排
在审批流、订单流、任务流里，也经常出现中介者思想。
比如订单创建后要协调：
- 库存服务；
- 优惠券服务；
- 支付服务；
- 通知服务；
- 风控服务。
如果这些模块互相直接调用，会出现强耦合。更常见的做法是让一个流程编排层协调它们。
但这里要小心：业务系统里的流程编排不一定严格等于 GoF 中介者模式，它可能还涉及事务、补偿、异步消息、状态机等架构能力。面试时可以说“体现了中介者思想”，不要把所有协调器都硬归类成中介者模式。
四、机场塔台模型
设计模式教材里常用机场塔台解释中介者模式。
飞机之间不能互相随意沟通，否则协调复杂且危险。飞机把起飞、降落、等待等请求告诉塔台，塔台根据跑道状态、天气、优先级统一调度。
映射到代码：
- 飞机是同事对象；
- 塔台是中介者；
- 调度规则在塔台中；
- 飞机之间不直接通信。
这个例子特别适合面试时讲“网状依赖变星型依赖”。
五、什么时候不该用
中介者模式不是所有通信问题的答案。
不适合使用的情况包括：
- 只有两个对象简单协作，直接调用更清晰；
- 协作规则很少，抽中介者会增加理解成本；
- 中介者没有清晰边界，只是把所有逻辑搬到一个类；
- 交互逻辑需要高度分布式治理，应该用消息队列、事件总线或流程引擎。
中介者模式适合代码级别的对象协作解耦，不应被无限放大成万能架构方案。
六、常见误区与追问
中介者适合参与者多且交互规则集中变化的场景。一个对话框有8个控件，状态联动若互相引用会迅速网状化；聊天室中用户也只需与房间中介者通信。若只有2个稳定对象单向调用，引入中介者反而让调用链变隐蔽。
| 检查维度 | 判定依据 |
|---|---|
| 高匹配 | 多参与者、网状依赖、协调规则明显 |
| 低匹配 | 少量对象、简单稳定的单向调用 |
UI控件/聊天室成员/航班 -> Mediator -> 协调结果心法：当对象开始互相“认识太多人”，才需要一个协调中心。
- 误区：消息队列天然就是中介者模式。 消息基础设施负责传输，是否协调业务参与者取决于上层设计。
- 追问：聊天室为什么适合？ 成员只向聊天室发送，加入退出和广播规则集中管理。
- 误区：工作流引擎只是一个大中介者。 它还包含状态机、持久化和调度等更广职责。
- 追问：航空调度场景的价值是什么？ 飞机不彼此协商跑道，由塔台集中避免冲突。
- 追问：什么时候应改用领域服务？ 协调内容本质是核心业务不变量时，应建模为领域服务而非泛化中介者。
七、加强记忆
中介者模式适合“对象多、交互乱、规则集中变化”的场景，尤其是 UI 联动、聊天室、塔台调度和模块协调。判断是否该用它，不看对象数量本身，而看对象之间是否已经形成网状依赖，以及协作规则是否值得集中维护。