设计模式之中介者模式

引言

某个工作日的早晨，小A发现楼栋电梯停运了。他打开物业小程序提交报修单，短短10分钟后，楼栋公告屏就亮起了提示：“电梯故障已受理，预计2小时内修复”。这看似简单的流程背后，隐藏着一个精密的协作系统：

物业中心在收到报修后同步触发：

1. 生成维修工单（自动派发给签约维保公司）
2. 启动临时安保预案（通知巡逻岗重点监控3栋）
3. 推送进度通知（居民小程序/短信/公告屏三端同步）

维修完成时，系统继续联动：

1. 关闭电梯警示标识（物联网设备远程控制）
2. 发起保洁工单（指定电梯井道清洁标准）
3. 更新设备档案（记录本次维修数据）
4. 发送恢复通知（附带电子版检修报告）

这正是中介者模式的经典实践——物业中心如同交通指挥台，让居民、维修队、保安队等20多个相关方无需直接对接，所有协作通过统一的中控系统完成。这种设计带来的三大优势显而易见：

• 解耦能手：维保公司更换时，居民端接口无需任何改动
• 扩展大师：新增水质检测服务只需扩展物业系统模块
• 审计专家：所有交互留痕形成完整追溯链条

如果缺失这个智能中枢：
小A可能需要逐个联系维修队长电话、到保安亭填写巡逻申请、在业主群刷屏提醒保洁，甚至要手动记录维修时间以备后续投诉。更麻烦的是，当小区引入垃圾代收服务时，每个住户都要重新获取清洁公司的联系方式、服务协议和支付接口——这种链式依赖正是软件系统失控的前兆。

中介者模式的精妙之处，在于它用「中间层」重新定义了协作规则。就像现代物业管理系统逐步集成智能调度算法，优秀的中介者类也应该具备路由决策、异常熔断、负载均衡等能力，而这一切对参与者来说都是透明的。

概念

定义

中介者模式是一种行为型设计模式。其核心思想是通过引入一个中介者对象来协调多个对象之间的交互，从而避免这些对象之间的直接依赖关系。这种模式的核心价值在于降低系统的耦合度，将原本复杂的网状交互结构转化为相对简单的星型结构。

如下图所示，不存在中介者的时候：

这种结构下，每个节点都需要知道其他所有节点的信息，耦合度极高。如果要修改其中一个节点的交互逻辑，可能需要修改与之相连的多个节点的代码，维护和扩展的难度非常大。

而加入中介者之后：

无论节点数量如何增加，每个节点只需要维护一个对中介者的引用，节点之间的耦合度大大降低。

当需要修改某个节点的交互逻辑时，只需要在中介者中进行相应的修改，而不需要修改其他节点的代码。同时，如果要添加新的节点，只需要让新节点与中介者建立联系，而不会影响到其他已有的节点，系统的可维护性和扩展性得到了显著提升。这充分体现了中介者模式将复杂的网状交互简化为星型交互，从而降低耦合度的优点。

核心组成

1. 中介者（Mediator）
   • 作为所有对象交互的中心点，封装了各个对象之间的通信逻辑。
   • 负责接收来自各个对象的请求，并根据规则协调其他对象的响应。
   • 避免对象之间直接调用，实现 “解耦”。
2. 同事（Colleague）
   • 需要交互的具体对象，它们只知道中介者的存在，通过中介者间接通信。
   • 每个同事类只需维护对中介者的引用，无需了解其他同事的细节。

如下图所示：

说明：

1. 抽象中介者（Mediator）
   • 声明notify方法，用于接收同事类的事件并协调响应。
   • 所有具体中介者必须实现此接口。
2. 具体中介者（ConcreteMediator）
   • 持有所有具体同事类的引用（colleagueA到colleagueD）。
   • 实现notify方法，根据事件类型调度不同同事的响应。
   • 通过setColleagueX方法关联具体同事类。
3. 抽象同事类（Colleague）
   • 维护对中介者的引用（通过构造函数注入）。
   • 提供sendMessage方法：同事类通过此方法向中介者发送事件。
   • 声明handleEvent抽象方法：由具体同事类实现业务逻辑。
4. 具体同事类（ConcreteColleagueA-D）
   • 继承Colleague，实现handleEvent处理具体事件。
   • 包含自身业务属性（如dataA、dataB）和方法（如doSomethingA()）。

交互流程

1. 发送事件：

   ConcreteColleagueA调用sendMessage("event1")，将事件传递给中介者。

2. 中介者调度：

   ConcreteMediator收到事件后，根据逻辑调用ConcreteColleagueB.handleEvent("event1")或其他同事类。

3. 响应事件：

   被调用的同事类（如ConcreteColleagueB）执行自身业务逻辑（如修改dataB）。

工作原理

中介者模式通过引入一个中间协调对象（中介者），将原本多个对象之间直接的网状交互关系转化为对象与中介者之间的星型交互关系。各对象不再直接调用其他对象的方法，而是通过中介者统一传递请求和响应，中介者负责处理各对象间的逻辑调度与数据传递。这种设计减少了对象间的直接耦合，降低了系统复杂度，使功能扩展和维护更集中可控。

示例

我们以引言中的例子编写示例代码。

C++实现

#include <iostream>
#include <memory>
#include <vector>
#include <string>// 前置声明
class Mediator;// 抽象同事类
class Colleague {
public:virtual void setMediator(std::shared_ptr<Mediator> mediator) = 0;virtual ~Colleague() = default;
};// 抽象中介者
class Mediator {
public:virtual void notify(const std::string& event, const std::string& sender) = 0;virtual ~Mediator() = default;
};// 具体同事类：维修服务
class MaintenanceService : public Colleague, public std::enable_shared_from_this<MaintenanceService> {
public:void setMediator(std::shared_ptr<Mediator> mediator) override {this->mediator_ = mediator;}void performRepair() {std::cout << "维修队开始处理电梯故障..." << std::endl;mediator_->notify("REPAIR_STARTED", "Maintenance");}void completeRepair() {std::cout << "维修队完成电梯修复工作" << std::endl;mediator_->notify("REPAIR_COMPLETED", "Maintenance");}private:std::shared_ptr<Mediator> mediator_;
};// 具体同事类：安保服务
class SecurityTeam : public Colleague {
public:void setMediator(std::shared_ptr<Mediator> mediator) override {this->mediator_ = mediator;}void focusMonitoring() {std::cout << "安保人员开始重点监控3栋电梯间" << std::endl;}void releaseMonitoring() {std::cout << "安保人员解除重点监控状态" << std::endl;}private:std::shared_ptr<Mediator> mediator_;
};// 具体同事类：通知系统
class NotificationSystem : public Colleague {
public:void setMediator(std::shared_ptr<Mediator> mediator) override {this->mediator_ = mediator;}void sendProgress() {std::cout << "系统推送：故障已受理（三端同步）" << std::endl;}void sendRecovery() {std::cout << "系统推送：电梯已恢复运行（含检修报告）" << std::endl;}private:std::shared_ptr<Mediator> mediator_;
};// 具体中介者：物业中心
class PropertyManagementCenter : public Mediator {
public:void addService(const std::shared_ptr<Colleague>& service) {services_.push_back(service);}void notify(const std::string& event, const std::string& sender) override {if (event == "REPORT_RECEIVED") {std::cout << "\n=== 开始处理报修流程 ===" << std::endl;maintenance_->performRepair();security_->focusMonitoring();notifications_->sendProgress();}else if (event == "REPAIR_COMPLETED") {std::cout << "\n=== 开始后续处理流程 ===" << std::endl;security_->releaseMonitoring();notifications_->sendRecovery();updateEquipmentRecords();scheduleCleaning();}}// 模拟其他系统接口void updateEquipmentRecords() {std::cout << "更新电梯设备维护档案" << std::endl;}void scheduleCleaning() {std::cout << "生成电梯井道清洁工单" << std::endl;}// 组件注入void setComponents(std::shared_ptr<MaintenanceService> maintenance,std::shared_ptr<SecurityTeam> security,std::shared_ptr<NotificationSystem> notifications) {maintenance_ = maintenance;security_ = security;notifications_ = notifications;}private:std::shared_ptr<MaintenanceService> maintenance_;std::shared_ptr<SecurityTeam> security_;std::shared_ptr<NotificationSystem> notifications_;std::vector<std::shared_ptr<Colleague>> services_;
};// 客户端使用
int main() {// 创建中介者auto mediator = std::make_shared<PropertyManagementCenter>();// 创建各个服务组件auto maintenance = std::make_shared<MaintenanceService>();auto security = std::make_shared<SecurityTeam>();auto notifications = std::make_shared<NotificationSystem>();// 组件注册到中介者mediator->setComponents(maintenance, security, notifications);maintenance->setMediator(mediator);security->setMediator(mediator);notifications->setMediator(mediator);// 模拟用户报修事件std::cout << "用户提交电梯报修申请..." << std::endl;mediator->notify("REPORT_RECEIVED", "Resident");// 模拟维修完成事件std::cout << "\n维修队反馈维修完成..." << std::endl;mediator->notify("REPAIR_COMPLETED", "Maintenance");return 0;
}

代码说明：

1. 模式结构：

• Mediator：抽象中介者接口，定义通知方法
• PropertyManagementCenter：具体中介者，协调各组件交互
• Colleague：抽象同事类，所有具体服务组件继承该接口
• 具体服务组件（维修/安保/通知）只与中介者通信

1. 扩展性体现：

• 新增服务只需继承Colleague并注册到中介者

• 交互逻辑集中在中介者，不影响现有组件

• 完整审计日志可通过中介者的notify方法统一记录

  上述代码只是展现简单示例，可以注意到在中介者内部处理具体事件时，使用了if else语句，但是随着功能增多，代码会变得臃肿难以维护，这并不符合开闭原则。可以根据具体情况使用通过事件映射表、策略方法、工厂模式等方式对中介者进行优化。

Java实现

import java.util.ArrayList;
import java.util.List;// 抽象同事接口
interface Colleague {void setMediator(Mediator mediator);
}// 抽象中介者接口
interface Mediator {void notify(String event, String sender);
}// 具体同事类：维修服务
class MaintenanceService implements Colleague {private Mediator mediator;@Overridepublic void setMediator(Mediator mediator) {this.mediator = mediator;}public void performRepair() {System.out.println("维修队开始处理电梯故障...");mediator.notify("REPAIR_STARTED", "Maintenance");}public void completeRepair() {System.out.println("维修队完成电梯修复工作");mediator.notify("REPAIR_COMPLETED", "Maintenance");}
}// 具体同事类：安保服务
class SecurityTeam implements Colleague {private Mediator mediator;@Overridepublic void setMediator(Mediator mediator) {this.mediator = mediator;}public void focusMonitoring() {System.out.println("安保人员开始重点监控3栋电梯间");}public void releaseMonitoring() {System.out.println("安保人员解除重点监控状态");}
}// 具体同事类：通知系统
class NotificationSystem implements Colleague {private Mediator mediator;@Overridepublic void setMediator(Mediator mediator) {this.mediator = mediator;}public void sendProgress() {System.out.println("系统推送：故障已受理（三端同步）");}public void sendRecovery() {System.out.println("系统推送：电梯已恢复运行（含检修报告）");}
}// 具体中介者：物业中心
class PropertyManagementCenter implements Mediator {private MaintenanceService maintenance;private SecurityTeam security;private NotificationSystem notifications;private List<Colleague> services = new ArrayList<>();public void setComponents(MaintenanceService maintenance, SecurityTeam security,NotificationSystem notifications) {this.maintenance = maintenance;this.security = security;this.notifications = notifications;}@Overridepublic void notify(String event, String sender) {if ("REPORT_RECEIVED".equals(event)) {System.out.println("\n=== 开始处理报修流程 ===");maintenance.performRepair();security.focusMonitoring();notifications.sendProgress();} else if ("REPAIR_COMPLETED".equals(event)) {System.out.println("\n=== 开始后续处理流程 ===");security.releaseMonitoring();notifications.sendRecovery();updateEquipmentRecords();scheduleCleaning();}}private void updateEquipmentRecords() {System.out.println("更新电梯设备维护档案");}private void scheduleCleaning() {System.out.println("生成电梯井道清洁工单");}public void addService(Colleague service) {services.add(service);}
}// 客户端使用
public class MediatorDemo {public static void main(String[] args) {// 创建中介者PropertyManagementCenter mediator = new PropertyManagementCenter();// 创建各个服务组件MaintenanceService maintenance = new MaintenanceService();SecurityTeam security = new SecurityTeam();NotificationSystem notifications = new NotificationSystem();// 组件注册到中介者mediator.setComponents(maintenance, security, notifications);maintenance.setMediator(mediator);security.setMediator(mediator);notifications.setMediator(mediator);// 模拟用户报修事件System.out.println("用户提交电梯报修申请...");mediator.notify("REPORT_RECEIVED", "Resident");// 模拟维修完成事件System.out.println("\n维修队反馈维修完成...");mediator.notify("REPAIR_COMPLETED", "Maintenance");}
}

中介者模式与代理模式的异同

对比维度	中介者模式	代理模式
相同点	- 均引入中间层解耦系统：代理隔离客户端与目标对象，中介者隔离同事对象间的直接交互。 - 均属于设计模式中的中间件思想，优化系统结构。
核心目的	减少多个对象间的耦合，集中协调复杂交互关系（行为型模式）	控制对单个对象的访问，增强或限制原对象的功能（结构型模式）
对象间关系	多对多：中介者管理多个同事对象，双向通信	一对一：代理对象仅代表一个目标对象，单向访问（客户端→代理→目标）
职责与功能	封装对象交互逻辑，实现复杂业务协调（如聊天室消息转发、系统模块解耦）	提供访问控制、延迟加载、权限验证等附加功能（如远程代理、安全代理）
设计原则	迪米特法则（减少对象间直接依赖）	单一职责原则（分离访问控制与核心逻辑）
适用场景	对象间交互复杂且需集中管理（如GUI组件通信、多玩家游戏协作）	需间接访问或增强目标对象（如网络代理、缓存代理、权限代理）
结构特点	包含中介者接口和多个同事类，中介者持有所有同事引用	代理类与目标类实现同一接口，客户端仅依赖代理
代码复杂度	中介者可能承担过多职责，导致类臃肿	代理类通常轻量，仅扩展特定功能

典型场景示例：

• 中介者模式：聊天室中用户通过服务器转发消息（多对多交互）；MVC架构中控制器协调模型与视图。
• 代理模式：远程服务调用（客户端通过本地代理访问远程对象）；图片懒加载（代理延迟加载大图）。

中介者模式的优缺点

优点

• 解耦对象之间的交互：中介者模式将对象之间的多对多交互转换为对象与中介者之间的一对多交互，使得各个对象不需要直接相互引用和了解，降低了对象之间的耦合度，提高了系统的可维护性和可扩展性。比如在一个复杂的游戏系统中，游戏角色之间的交互通过中介者来处理，每个角色不需要知道其他角色的具体细节，只需要与中介者通信。
• 提高可复用性：中介者类可以被多个不同的对象复用，因为它封装了对象之间的交互逻辑。只要符合中介者定义的接口规范，新的对象也可以很容易地接入到系统中，利用中介者来进行交互，而不需要重复编写交互逻辑。
• 简化系统维护：由于对象之间的交互逻辑集中在中介者类中，而不是分散在各个对象之间，当需要对交互逻辑进行修改或扩展时，只需要在中介者类中进行操作，而不需要在多个相关对象中进行修改，降低了维护的难度和成本，提高了系统的稳定性。
• 便于集中管理和控制：中介者模式将所有的交互逻辑集中在一个中介者对象中，使得对系统的控制和管理更加方便。可以在中介者中方便地实现对交互的监控、日志记录、事务处理等功能，有利于系统的性能优化、问题排查和安全控制等。

缺点

• 中介者职责过重：随着系统中对象之间交互逻辑的增加，中介者类可能会变得非常复杂，承担过多的职责，导致中介者类自身难以维护和理解。这可能会违反单一职责原则，使得中介者类成为一个庞大而复杂的“上帝对象”。
• 可能影响性能：所有对象之间的交互都要通过中介者来进行，在一些性能要求极高的场景下，可能会增加系统的通信开销和处理时间，导致性能下降。特别是当系统中有大量对象频繁进行交互时，中介者可能会成为性能瓶颈。
• 过度使用可能导致设计复杂：如果在设计系统时，不恰当地过度使用中介者模式，将一些本可以由对象自身简单处理的事情也交给中介者来处理，可能会使系统的设计变得过于复杂，增加了不必要的抽象层次，反而不利于系统的开发和维护。

注意事项

使用中介者模式时，需要关注以下几个方面的注意事项：

设计层面

• 合理界定中介者职责
• 中介者应仅负责协调对象间的交互，避免承担过多与交互无关的业务逻辑。比如在一个电商系统中，订单、商品和用户之间的交互由中介者协调，但商品的库存计算、用户的积分规则等业务逻辑不应放入中介者中，否则会使中介者变得臃肿复杂，难以维护。
• 遵循单一职责原则，确保中介者的功能清晰明确，只专注于管理对象间的通信。
• 谨慎引入中介者
• 并非所有对象间的交互都需要中介者。如果系统中对象之间的交互简单且不频繁，引入中介者可能会增加系统的复杂度和维护成本。例如，一个简单的计算器程序，两个数字输入框和计算结果显示框之间的交互直接处理即可，无需引入中介者。
• 只有当对象间存在复杂的多对多交互关系，且这种交互逻辑需要集中管理和维护时，才考虑使用中介者模式。
• 确保良好的可扩展性
• 设计中介者接口和具体实现时，要考虑到未来可能的功能扩展。例如，在一个多人游戏系统中，随着游戏功能的增加，可能会有新的角色类型或交互规则，中介者应具备良好的扩展性，能够方便地添加新的交互逻辑。
• 采用面向接口编程，使中介者和具体对象之间通过接口进行交互，降低耦合度，便于后续的扩展和修改。

实现层面

• 控制中介者的复杂度
• 当交互逻辑复杂时，可以将中介者的功能进行拆分，使用多个中介者类或引入中介者的层次结构。例如，在一个大型的企业信息系统中，不同部门之间的交互可以由不同的中介者负责，然后通过一个总中介者进行协调。
• 避免在中介者中编写过于复杂的条件判断和嵌套逻辑，可采用策略模式等其他设计模式来简化逻辑。
• 注意对象与中介者的通信机制
• 选择合适的通信方式，如消息传递、事件驱动等。在一个图形界面应用程序中，组件之间的交互可以通过事件机制通知中介者，中介者再根据事件类型进行相应的处理。
• 确保对象和中介者之间的通信高效、稳定，避免出现消息丢失、重复处理等问题。
• 处理好异常情况
• 在中介者处理对象间交互时，要考虑各种可能的异常情况，如对象未正确初始化、通信失败等。例如，在一个分布式系统中，中介者与对象之间的网络通信可能会出现中断，需要有相应的异常处理机制，如重试、错误提示等。
• 对异常情况进行详细的日志记录，方便后续的问题排查和系统维护。

维护层面

• 文档和注释
• 为中介者类和相关对象添加详细的文档和注释，说明其功能、交互逻辑和使用方法。这对于后续的开发人员理解系统设计和进行维护工作非常重要。
• 特别是对于复杂的交互逻辑，要通过注释清晰地描述每个步骤的目的和实现思路。
• 测试覆盖
• 对中介者模式的实现进行全面的测试，包括单元测试、集成测试等。测试用例应覆盖各种正常和异常情况，确保中介者能够正确处理对象间的交互。
• 例如，在一个社交网络系统中，测试中介者是否能正确处理用户之间的好友请求、消息发送等交互操作。

设计原则

迪米特法则（Law of Demeter，LoD）

• 含义：也称为最少知识原则，一个对象应该对其他对象有最少的了解。也就是说，一个对象应该只和它的直接朋友通信，而避免和陌生对象直接交互。
• 在中介者模式中的体现：在中介者模式里，各个同事对象（参与交互的对象）之间不直接进行通信，而是通过中介者进行间接通信。每个同事对象只需要知道中介者对象，而不需要了解其他同事对象的内部细节和交互方式。这样就减少了对象之间的依赖关系，降低了系统的耦合度，符合迪米特法则。例如在一个航空公司的航班调度系统中，各个航班（同事对象）不需要直接与其他航班沟通，而是通过调度中心（中介者）来协调起降时间等信息，每个航班只与调度中心这一“直接朋友”进行交互。

单一职责原则（Single Responsibility Principle，SRP）

• 含义：一个类应该只有一个引起它变化的原因，即一个类只负责一项职责。
• 在中介者模式中的体现：中介者模式将对象之间的交互逻辑集中到中介者类中，使得每个同事对象只需要关注自身的业务逻辑，而将对象间的交互职责交给中介者。这样，同事对象和中介者对象都遵循了单一职责原则。比如在一个在线购物系统中，商品类（同事对象）只负责处理商品的基本信息和操作，如展示商品详情、修改库存等；而订单的生成、商品与用户之间的交互等逻辑则由订单管理中介者负责，每个类的职责清晰明确。

开闭原则（Open/Closed Principle，OCP）

• 含义：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即当有新的需求时，应该通过扩展现有代码来实现，而不是修改已有的代码。
• 在中介者模式中的体现：当需要添加新的同事对象或者新的交互逻辑时，可以通过扩展中介者类或者添加新的具体中介者来实现，而不需要修改现有的同事对象和中介者的核心代码。例如在一个游戏系统中，最初只有玩家角色和怪物角色之间的交互，随着游戏的更新，需要添加新的NPC角色参与交互，此时可以通过扩展中介者类来处理新的交互逻辑，而不需要修改原有的玩家和怪物角色的代码。

依赖倒置原则（Dependency Inversion Principle，DIP）

• 含义：高层模块不应该依赖低层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。
• 在中介者模式中的体现：中介者模式中，同事对象和中介者之间通常通过抽象接口进行交互。同事对象依赖于中介者的抽象接口，而不是具体的中介者实现；中介者也依赖于同事对象的抽象接口，而不是具体的同事类。这样就降低了对象之间的耦合度，提高了系统的灵活性和可维护性。例如在一个智能家居系统中，各种智能设备（同事对象）依赖于智能家居中介者的抽象接口，而智能家居中介者也依赖于智能设备的抽象接口，当更换不同品牌或类型的智能设备时，只需要实现相应的抽象接口，而不需要修改中介者和其他设备的代码。

应用场景

中介者模式适用于多种存在复杂交互关系的场景，如以下几类：

系统交互场景

• 图形用户界面系统：在图形界面中，往往存在多个组件之间的交互，如菜单、按钮、文本框、列表框等。这些组件之间的交互逻辑如果直接实现，会导致组件之间的耦合度很高，难以维护和扩展。使用中介者模式，可以将组件之间的交互通过一个中介者对象来管理。例如，当用户点击一个按钮时，按钮并不直接与其他组件交互，而是将事件通知给中介者，由中介者来决定如何更新文本框、列表框等其他组件的状态。
• 分布式系统：在分布式系统中，不同的节点之间需要进行通信和协作。中介者模式可以用于管理这些节点之间的交互，将节点之间的复杂通信和协调逻辑封装在中介者中。比如，在一个分布式文件系统中，不同的存储节点之间的文件读写请求、数据同步等操作可以通过一个文件系统中介者来协调，各个存储节点只需要与中介者进行交互，而不需要了解其他节点的具体情况。

游戏开发场景

• 多人在线游戏：在多人在线游戏中，玩家之间的交互、玩家与游戏环境的交互等都非常复杂。中介者模式可以用于管理这些交互，例如，游戏中的聊天系统，玩家发送的聊天消息不是直接发送给其他玩家，而是通过聊天中介者来转发；游戏中的战斗系统，玩家之间的攻击、防御等操作也可以通过战斗中介者来协调，确保游戏的平衡性和公平性。
• 游戏角色管理：游戏中的各种角色，如玩家角色、NPC角色等，它们之间的交互也可以使用中介者模式。例如，在一个角色扮演游戏中，玩家角色与NPC角色之间的对话、任务交互等，都可以通过一个角色交互中介者来管理。这样可以将角色之间的交互逻辑集中处理，方便游戏的开发和维护。

企业应用场景

• 企业业务流程管理：企业中的各种业务流程，如订单处理流程、采购流程、审批流程等，涉及多个部门和系统之间的协作。中介者模式可以用于管理这些流程中的交互，将不同部门和系统之间的通信和协调逻辑封装在一个中介者中。例如，在订单处理流程中，销售部门、库存管理部门、物流部门之间的信息交互可以通过订单中介者来协调，确保订单的顺利处理。
• 企业信息系统集成：企业通常会使用多个信息系统，如ERP系统、CRM系统、OA系统等，这些系统之间需要进行数据共享和交互。中介者模式可以用于实现这些系统之间的集成，通过一个中介者来管理不同系统之间的数据传输和交互逻辑。比如，当在CRM系统中创建一个新客户时，需要将客户信息同步到ERP系统中，这个过程可以通过一个信息集成中介者来完成。

交通调度场景

• 机场航班调度：机场的航班调度涉及到多个方面的协调，如飞机的起降、跑道的分配、候机楼的安排、行李的运输等。中介者模式可以用于管理这些复杂的交互，通过一个航班调度中介者来协调各个环节之间的工作，确保航班的正常运行。
• 城市交通管理：在城市交通管理中，交通信号灯的控制、车辆的流量调度、公交地铁的运营等都需要进行协调。中介者模式可以用于实现这些协调功能，例如，通过一个交通管理中介者来根据路况信息调整交通信号灯的时长，调度公交车的行驶路线等，以提高城市交通的效率。