1. 从“混乱”到“清晰”为什么我们需要中介者模式如果你写过一些稍微复杂的业务代码尤其是那种涉及多个对象之间相互通信和协作的场景很可能遇到过这样的困境一个类里塞满了对其他类的引用A 要调用 B 和 C 的方法B 的状态变化需要通知 A 和 DC 和 D 之间又有数据交换……整个系统的类图看起来就像一张密密麻麻的蜘蛛网牵一发而动全身。修改任何一个类都可能需要去改动好几个与之通信的类代码的耦合度高得吓人维护和扩展的成本呈指数级增长。这种对象间复杂的网状引用关系就是典型的“过度耦合”问题。中介者模式Mediator Pattern就是为了解决这个问题而生的。它的核心思想非常直观与其让所有对象都互相认识、直接对话不如引入一个“中间人”。这个“中间人”就是中介者Mediator它负责协调和管理一组对象称为同事对象Colleague之间的交互。所有同事对象都只和中介者通信由中介者来转发请求、协调行动。这样一来原本混乱的网状结构就变成了清晰的星型结构。每个同事对象只需要知道中介者这一个“上级”大大降低了系统的耦合度。想象一下一个机场的空中交通管制塔台。如果没有塔台中介者每一架飞机同事对象都需要直接与其他所有飞机通信协商航线、高度、速度那将是灾难性的。而有了塔台所有飞机只与塔台通信塔台掌握全局信息协调所有飞机的起降和航线确保了整个空域的安全和高效。中介者模式在软件设计中扮演的就是这个“塔台”的角色。在 Java、C、C# 乃至 Unity 游戏开发中中介者模式都是一个非常经典且实用的行为型设计模式。它特别适用于那些对象间交互关系复杂多变且这种关系本身也需要独立演化的场景。接下来我们就深入拆解这个模式的方方面面。2. 中介者模式的核心结构角色与协作关系要理解一个设计模式首先得看清它的“骨架”。中介者模式的结构清晰定义了四个关键角色它们之间的协作关系构成了模式的基础。2.1 四大核心角色解析1. 中介者接口Mediator这是一个接口或抽象类它定义了用于与各个同事对象进行通信的方法。通常这些方法会接收一个同事对象作为参数以便中介者知道消息来自谁。例如一个notify(Colleague sender, String event)方法就很常见。这个接口是所有具体中介者的契约。2. 具体中介者ConcreteMediator这是模式的核心实现者。它实现了中介者接口并且知晓并维护了所有需要被协调的同事对象的引用。具体中介者包含了对象间协作的具体业务逻辑。当某个同事对象发出通知时具体中介者会根据发送者、事件类型以及其他同事的当前状态来决定如何影响其他同事对象。它是整个交互网络的“大脑”。3. 同事类接口Colleague这也是一个接口或抽象类它定义了所有同事对象的通用行为。最关键的一点是它通常会持有一个对中介者对象的引用。这样每个同事对象都知道该向谁发送消息。这个引用通常在构造函数中注入。4. 具体同事类ConcreteColleague实现了同事类接口的具体类。每个具体同事对象在需要与其他同事通信时不会直接调用对方的方法而是通过它持有的中介者引用来发送消息。它只负责自己的核心业务逻辑而将与其他对象的协调工作完全委托给中介者。2.2 协作流程与数据流向他们之间的协作遵循一个固定的流程我们可以用一个简单的“聊天室”例子来贯穿说明初始化在系统启动时会创建一个具体中介者例如ChatRoom和多个具体同事对象例如UserA,UserB。在创建同事对象时会将中介者实例传递给它们依赖注入。同事对象触发事件当某个同事对象如UserA的状态发生变化或需要执行某个动作时比如发送一条消息它不会直接去找UserB而是调用自身的方法如sendMessage。委托中介者在sendMessage方法内部UserA会调用它所持有的中介者引用上的一个方法例如mediator.relayMessage(this, message)。这里this代表了发送者自身message是事件内容。中介者协调具体中介者ChatRoom的relayMessage方法被调用。它接收到发送者UserA和消息内容。此时中介者根据内置的业务逻辑比如将消息广播给除发送者外的所有用户遍历它所维护的其他同事对象UserB,UserC...并调用它们的方法如receiveMessage。同事对象响应其他同事对象如UserB的receiveMessage方法被中介者调用从而接收到消息并做出相应处理如显示在界面上。整个过程中UserA和UserB完全没有直接接触。所有的交互逻辑都集中在了ChatRoom这个中介者中。数据流向是从一个同事对象流经中介者再分发给其他相关的同事对象。注意这里有一个关键设计决策。同事对象通知中介者的方法和中介者调用同事对象的方法其粒度可以不同。例如同事可能统一调用mediator.notify(sender, “eventType”)而中介者内部则根据“eventType”来执行不同的协调逻辑调用同事对象不同的具体方法。这提供了更好的灵活性。3. 深入原理解耦的本质与实现机制中介者模式的原理远不止于引入一个中间类那么简单。它的威力在于通过一种结构化的方式实现了对象间交互逻辑的“转移”与“集中管理”这背后是深刻的解耦思想。3.1 从“多对多”到“一对多”的拓扑结构转变这是最直观的原理。在没有中介者的情况下N 个对象之间如果要两两通信最多可能存在N*(N-1)条直接的引用关系。这是一个完全图耦合是网状、爆炸性的。引入中介者后每个对象只与中介者建立一条关联总共 N 条关联。中介者自身则与所有 N 个对象关联。系统的拓扑结构从“多对多”的网状变成了以中介者为中心的“一对多”星型。这种转变带来的直接好处是修改一个同事类的通信行为只需要修改中介者即可其他同事类无需变动。例如在聊天室例子中如果我们想增加一个“私聊”功能只需要修改ChatRoom中介者的relayMessage逻辑让它能够识别接收者并定向发送。UserA和UserB的发送和接收消息的代码完全不用改。3.2 交互逻辑的封装与复用中介者模式将原本分散在各个同事对象中的交互逻辑集中到了中介者这一个类中。这实际上是对“对象间如何协作”这部分业务逻辑进行了封装。这种封装带来了两个巨大的优势可维护性当交互规则发生变化时比如消息发送前需要先进行敏感词过滤你只需要在一个地方中介者类进行修改而不是在所有可能发送消息的同事类中逐一修改。可复用性这套协调逻辑被独立出来了。如果未来有另一组对象需要类似的协调方式比如另一个主题的聊天室你可以复用这个中介者类或者通过继承、组合的方式扩展它而不必重新编写散布的交互代码。3.3 控制反转IoC思想的体现中介者模式是控制反转Inversion of Control原则的一个典型应用。在传统直接调用的方式中同事对象拥有控制权——它决定何时调用谁。而在中介者模式中这个控制权被反转了同事对象只是发出一个事件通知至于这个事件如何处理、会影响谁完全由中介者来决定。同事对象失去了对交互流程的直接控制变成了被动的参与者。这种反转使得系统的控制流更加清晰和中心化。中介者成为了系统的“协调器”或“控制器”这非常类似于 MVC 模式中的控制器Controller角色它负责接收视图View的事件并调度模型Model进行响应。3.4 与观察者模式的联系与区别很多人容易将中介者模式与观察者模式混淆因为它们都涉及对象间的通知。但它们的关注点有本质不同观察者模式定义了一种一对多的依赖关系当一个对象主题状态改变时所有依赖于它的对象观察者都会得到通知并自动更新。重点是状态的自动同步和广播。观察者之间通常不知道彼此的存在。中介者模式定义了一个封装一组对象交互的对象。重点是复杂的、双向的、定制化的交互协调。同事对象之间不直接通信但中介者可以根据复杂的业务逻辑决定如何让同事对象相互影响。实际上它们经常结合使用。中介者内部可以使用观察者模式来管理同事对象中介者作为“主题”同事对象作为“观察者”注册到中介者上。当某个同事发出事件时中介者作为主题状态变化进而通知其他注册的同事观察者。但这种结合使用时中介者依然保留了其协调复杂逻辑的核心职责观察者只是其内部实现通知的一种技术手段。4. 模式的优缺点何时该用何时该慎用没有一个设计模式是银弹中介者模式在带来巨大好处的同时也伴随着其固有的代价。清晰地认识其优缺点是正确应用它的前提。4.1 核心优势极大降低耦合度这是中介者模式最核心的价值。它将对象间错综复杂的网状依赖简化为所有对象只依赖于中介者。这使得各个同事类可以独立地变化和复用符合“高内聚、低耦合”的设计原则。集中控制交互将多个对象间复杂的交互逻辑集中到一个中介者对象中使得这些交互行为变得清晰、易于理解和维护。当交互规则需要变更时修改点单一降低了出错风险。简化对象协议原本对象之间可能需要定义多种复杂的通信协议API。现在每个对象只需要实现与中介者通信的简单接口即可协议被大大简化。有利于对象复用由于同事类不再包含与其他对象交互的“环境相关”代码它们可以更容易地被复用到不同的上下文中只需要为其提供一个新的中介者即可。4.2 潜在缺点与挑战中介者可能演变为“上帝对象”这是中介者模式最容易掉入的陷阱。随着系统演进越来越多的交互逻辑被塞进中介者导致中介者类的职责不断膨胀最终变成一个庞大、复杂、难以维护的“上帝类”God Class。它什么都管违反了单一职责原则。增加了系统的复杂度引入中介者意味着在系统中增加了一个新的抽象层和一系列新的交互接口。对于简单的、对象间交互不多的系统使用中介者模式无疑是“杀鸡用牛刀”反而让设计变得更复杂。性能考量所有的通信都需要经过中介者转发这可能会引入微小的性能开销。在极端高性能要求的场景下这可能成为一个考量点尽管在绝大多数业务系统中可忽略不计。4.3 适用场景判断指南那么到底什么时候该用中介者模式呢你可以通过回答下面几个问题来判断系统中是否存在一组对象它们之间的通信关系复杂且网状交错画一下类图如果连线多得让你头疼就该考虑了。这些对象之间的交互逻辑是否频繁变化或者预期未来会频繁变化如果是将变化点隔离到中介者中是明智的。你是否希望这些对象能够独立地被复用而不依赖于特定的交互环境中介者模式有助于实现这一点。你能否清晰地定义一个“协调者”的角色这个角色应该具有明确的职责边界而不是一个什么都能管的“大杂烩”。典型的应用场景包括GUI 开发中的对话框/表单对话框中的多个控件按钮、输入框、复选框相互影响。例如选中某个复选框会禁用一组输入框填写某个输入框会实时验证并提示另一个按钮是否可用。使用一个对话框中介者来协调所有控件的状态是最佳实践。聊天应用程序如前所述聊天室服务器就是一个典型的中介者协调所有用户的消息收发、广播、私聊、禁言等。航空交通管制系统、游戏中的AI决策系统这些场景需要中心化的协调器来处理多个实体飞机、游戏单位之间的冲突、协作和规则判定。工作流引擎引擎作为中介者协调流程中各个任务节点同事对象的启动、暂停、跳转和条件判断。5. 实战示例构建一个可扩展的智能家居控制中心理论说得再多不如一行代码。让我们用一个更贴近实际、更具扩展性的例子——智能家居控制中心——来完整实现一遍中介者模式。这个例子比简单的聊天室更能体现中介者协调复杂、差异化交互的能力。假设我们有一个智能家居系统包含以下设备智能灯可以打开、关闭、调节亮度。智能窗帘可以打开、关闭。空调可以打开、关闭、设置模式制冷/制热和温度。安防传感器检测到异常如有人闯入时发出警报。这些设备之间需要智能联动“电影模式”当用户启动电影模式灯光调暗至30%窗帘关闭空调调至静音模式。“离家模式”关闭所有灯光和窗帘空调切换为节能模式安防系统布防。“安防警报”当传感器触发警报所有灯光闪烁红色窗帘全部打开便于查看空调关闭。如果让每个设备直接去调用其他设备代码将混乱不堪。中介者模式是完美的解决方案。5.1 定义中介者与同事接口首先我们定义核心接口。同事接口所有智能设备的共同父类或接口。// 同事类接口 public abstract class SmartDevice { protected SmartHomeMediator mediator; protected String name; public SmartDevice(String name, SmartHomeMediator mediator) { this.name name; this.mediator mediator; // 注册自己到中介者 this.mediator.registerDevice(this); } // 设备接收来自中介者的命令 public abstract void receiveCommand(String command, Object... args); // 设备发送事件给中介者例如传感器触发 public void sendEvent(String event, Object... args) { mediator.relayEvent(this, event, args); } public String getName() { return name; } }中介者接口// 中介者接口 public interface SmartHomeMediator { // 注册设备 void registerDevice(SmartDevice device); // 接收来自设备的事件并进行协调 void relayEvent(SmartDevice sender, String event, Object... args); // 执行场景模式 void executeScene(String sceneName); }5.2 实现具体同事类智能设备我们实现几个简单的具体设备。为了聚焦于模式省略了真实的硬件控制代码。// 具体同事类智能灯 public class SmartLight extends SmartDevice { private boolean isOn false; private int brightness 100; // 亮度百分比 public SmartLight(String name, SmartHomeMediator mediator) { super(name, mediator); } Override public void receiveCommand(String command, Object... args) { switch (command) { case TURN_ON: isOn true; System.out.println(name 已打开。); break; case TURN_OFF: isOn false; System.out.println(name 已关闭。); break; case SET_BRIGHTNESS: if (args.length 0 args[0] instanceof Integer) { brightness (Integer) args[0]; System.out.println(name 亮度设置为 brightness %。); } break; case BLINK_RED: System.out.println(name 正在闪烁红光警报); break; } } // 设备自身的方法 public void turnOn() { sendEvent(LIGHT_TURNED_ON); } public void turnOff() { sendEvent(LIGHT_TURNED_OFF); } } // 具体同事类智能窗帘 public class SmartCurtain extends SmartDevice { private boolean isOpen false; public SmartCurtain(String name, SmartHomeMediator mediator) { super(name, mediator); } Override public void receiveCommand(String command, Object... args) { switch (command) { case OPEN: isOpen true; System.out.println(name 已打开。); break; case CLOSE: isOpen false; System.out.println(name 已关闭。); break; } } } // 具体同事类安防传感器 public class SecuritySensor extends SmartDevice { public SecuritySensor(String name, SmartHomeMediator mediator) { super(name, mediator); } Override public void receiveCommand(String command, Object... args) { // 传感器通常只发送事件不接收复杂命令可能接收布防/撤防 if (ARM.equals(command)) { System.out.println(name 已布防。); } else if (DISARM.equals(command)) { System.out.println(name 已撤防。); } } // 模拟传感器触发 public void triggerAlarm() { System.out.println(name 检测到异常发送警报事件。); sendEvent(INTRUSION_ALARM); } }5.3 实现具体中介者家居控制中心这是模式的核心包含了所有的协调逻辑。// 具体中介者智能家居控制中心 public class HomeControlCenter implements SmartHomeMediator { private MapString, SmartDevice devices new HashMap(); private MapString, Runnable scenes new HashMap(); public HomeControlCenter() { // 预定义场景 defineScenes(); } Override public void registerDevice(SmartDevice device) { devices.put(device.getName(), device); System.out.println(设备已注册: device.getName()); } Override public void relayEvent(SmartDevice sender, String event, Object... args) { System.out.println(控制中心收到来自 [ sender.getName() ] 的事件: event); // 根据事件类型进行协调 switch (event) { case INTRUSION_ALARM: handleIntrusionAlarm(); break; case LIGHT_TURNED_ON: // 可以在这里添加其他逻辑例如如果晚上开灯自动关闭窗帘 // System.out.println(检测到开灯事件可能触发其他设备...); break; // 可以处理更多设备事件... default: System.out.println(未处理的事件类型: event); } } Override public void executeScene(String sceneName) { Runnable scene scenes.get(sceneName); if (scene ! null) { System.out.println(--- 执行场景: sceneName ---); scene.run(); System.out.println(--- 场景执行完毕 ---); } else { System.out.println(未知场景: sceneName); } } // 处理安防警报的复杂协调逻辑 private void handleIntrusionAlarm() { System.out.println(安防警报触发协调所有设备); for (SmartDevice device : devices.values()) { if (device instanceof SmartLight) { device.receiveCommand(BLINK_RED); } else if (device instanceof SmartCurtain) { device.receiveCommand(OPEN); // 打开窗帘以便查看 } else if (device instanceof AirConditioner) { // 假设有空调类 device.receiveCommand(TURN_OFF); } // 传感器本身可能不需要额外操作 } // 还可以在这里触发通知主人、报警等更高层逻辑 } // 定义场景 private void defineScenes() { scenes.put(MOVIE_MODE, () - { devices.values().forEach(device - { if (device instanceof SmartLight) { device.receiveCommand(SET_BRIGHTNESS, 30); } else if (device instanceof SmartCurtain) { device.receiveCommand(CLOSE); } else if (device instanceof AirConditioner) { device.receiveCommand(SET_MODE, SILENT); } }); }); scenes.put(LEAVE_HOME_MODE, () - { devices.values().forEach(device - { if (device instanceof SmartLight) { device.receiveCommand(TURN_OFF); } else if (device instanceof SmartCurtain) { device.receiveCommand(CLOSE); } else if (device instanceof AirConditioner) { device.receiveCommand(SET_MODE, ECO); } else if (device instanceof SecuritySensor) { device.receiveCommand(ARM); } }); }); } // 提供一个方法来获取设备便于测试 public SmartDevice getDevice(String name) { return devices.get(name); } }5.4 客户端使用与测试最后我们编写客户端代码来组装整个系统并测试场景。public class SmartHomeClient { public static void main(String[] args) { // 1. 创建中介者控制中心 HomeControlCenter controlCenter new HomeControlCenter(); // 2. 创建各个智能设备并注册到控制中心在构造函数中完成 SmartLight livingRoomLight new SmartLight(客厅主灯, controlCenter); SmartCurtain livingRoomCurtain new SmartCurtain(客厅窗帘, controlCenter); SecuritySensor frontDoorSensor new SecuritySensor(前门传感器, controlCenter); // 假设我们有空调类 AirConditioner livingRoomAC new AirConditioner(客厅空调, controlCenter); System.out.println(\n 测试场景模式 ); controlCenter.executeScene(MOVIE_MODE); System.out.println(\n 测试离家模式 ); controlCenter.executeScene(LEAVE_HOME_MODE); System.out.println(\n 模拟安防警报 ); // 模拟传感器触发警报 frontDoorSensor.triggerAlarm(); // 传感器发送事件中介者协调所有设备 System.out.println(\n 测试设备直接交互通过中介者); // 用户手动打开客厅灯这个动作也会被中介者捕获通过事件但可能不触发复杂联动 livingRoomLight.turnOn(); } }输出结果示例设备已注册: 客厅主灯 设备已注册: 客厅窗帘 设备已注册: 前门传感器 设备已注册: 客厅空调 测试场景模式 --- 执行场景: MOVIE_MODE --- 客厅主灯 亮度设置为 30%。 客厅窗帘 已关闭。 客厅空调 模式设置为 SILENT。 --- 场景执行完毕 --- 测试离家模式 --- 执行场景: LEAVE_HOME_MODE --- 客厅主灯 已关闭。 客厅窗帘 已关闭。 客厅空调 模式设置为 ECO。 前门传感器 已布防。 --- 场景执行完毕 --- 模拟安防警报 前门传感器 检测到异常发送警报事件。 控制中心收到来自 [前门传感器] 的事件: INTRUSION_ALARM 安防警报触发协调所有设备 客厅主灯 正在闪烁红光警报 客厅窗帘 已打开。 客厅空调 已关闭。 测试设备直接交互通过中介者 控制中心收到来自 [客厅主灯] 的事件: LIGHT_TURNED_ON5.5 示例分析与经验总结通过这个完整的示例我们可以深刻体会到中介者模式的威力清晰的职责分离SmartLight只关心如何开关和调光SecuritySensor只负责检测和报警。它们完全不知道还有其他设备存在。所有的“智能联动”逻辑都封装在HomeControlCenter这个中介者中。极高的可扩展性如果要增加一个新设备比如“智能音响”我们只需要创建一个SmartSpeaker类继承SmartDevice。在HomeControlCenter的relayEvent方法或某个场景中增加对SmartSpeaker事件的响应逻辑。现有的所有其他设备类完全不需要修改。灵活的场景管理我们将场景MOVIE_MODE,LEAVE_HOME_MODE定义在中介者内部作为预置的协调脚本。这使得增加、修改或删除一个场景变得非常容易所有改动都集中在一处。避免了“上帝对象”陷阱在这个设计中HomeControlCenter的职责是明确的——“协调智能家居设备”。它不负责设备的内部实现如怎么调光也不负责更高层的业务逻辑如用户管理、定时任务。如果未来系统变得极其复杂我们可以考虑进一步拆分中介者例如按房间LivingRoomMediator,BedRoomMediator或按功能SecurityMediator,ComfortMediator划分形成多个中介者协同工作的结构。一个重要的实操心得在设计中介者接口时relayEvent方法的参数设计非常关键。示例中我们使用了String event和可变参数Object... args这是一种简单灵活的方式。但在大型项目中更推荐使用专门的事件对象Event Object。例如定义一个DeviceEvent基类然后派生出AlarmEvent、StateChangeEvent等里面包含更丰富的类型安全的数据。这样中介者的relayEvent方法签名会变成void relayEvent(DeviceEvent event)代码会更加清晰和可维护。