首页/资讯中心/详情

C++中介者模式实战：解耦复杂对象交互，重构清晰架构

C++中介者模式实战：解耦复杂对象交互，重构清晰架构
📅 发布时间：2026/7/13 4:46:58

1. 中介者模式：从“混乱连线”到“清晰枢纽”的架构重构

如果你写过稍微复杂一点的GUI程序，或者设计过一个包含多个交互对象的业务模块，大概率遇到过这种场景：十几个对象互相持有对方的引用，A的状态变化需要通知B和C，B的操作又会影响D和E，最后代码里到处都是objectB->update()、objectC->onEvent()这样的直接调用。整个模块的依赖关系图看起来像一团乱麻，牵一发而动全身，加个新功能或者改个交互逻辑都得小心翼翼，生怕哪里没改到。这种“网状耦合”正是中介者模式要解决的核心痛点。

中介者模式，顾名思义，就是引入一个“中介者”角色，让所有需要交互的对象（称为“同事对象”）不再直接对话，而是通过这个中介者来转发请求和协调行动。想象一下，如果没有机场塔台（中介者），每架飞机（同事对象）都得直接和其他所有飞机通信来协调起飞、降落、航线，那将是灾难。塔台的出现，让飞机之间解耦，只需和塔台通信，由塔台这个统一的协调者来管理全局秩序。在软件里，这个“塔台”就是一个中介者类，它知晓所有同事对象，并封装了它们之间的交互逻辑。

在C++中实现中介者模式，不仅仅是多写一个类那么简单。它涉及到如何设计一个灵活的通信接口、如何处理同事对象与中介者的双向引用、如何避免中介者自身变成另一个“上帝类”导致过度复杂。很多资料只给个概念示例，但实际项目中，内存管理（尤其是C++里）、线程安全、中介者逻辑的膨胀都是绕不开的坑。这篇文章，我会结合我这些年做桌面应用和游戏UI模块的实际经验，把中介者模式在C++里的门道讲透，包括经典实现、实用变种、那些容易踩的坑，以及如何判断你的场景是否真的需要用这个模式。

2. 核心思想与架构价值：为什么是“行为型”模式？

中介者模式被归类为“行为型设计模式”，这一点很重要。它主要关注的是对象之间如何交互、职责如何分配，也就是“行为”的协调，而不是对象的创建（创建型）或组合方式（结构型）。它的核心价值在于限制对象间的直接交互，迫使它们通过一个中介对象进行协作，从而将混乱的网状结构变为清晰的星型结构。

2.1 问题场景：紧耦合的“聊天室”

假设我们在用C++写一个简易聊天程序，最初的设计可能很直接：每个User对象都持有一个其他所有User对象的列表或向量。

// 紧耦合的设计 - 每个用户都知道其他所有人 class User { public: User(const std::string& name) : name_(name) {} void sendMessage(const std::string& msg, User* target) { std::cout << name_ << " to " << target->getName() << ": " << msg << std::endl; target->receiveMessage(msg, this); } void receiveMessage(const std::string& msg, User* sender) { std::cout << name_ << " received from " << sender->getName() << ": " << msg << std::endl; } std::string getName() const { return name_; } void addFriend(User* user) { /* 管理好友列表，复杂度开始上升 */ } private: std::string name_; std::vector<User*> friends_; // 依赖开始滋生 };

这个设计的问题会随着功能增加而爆发：

  1. 添加新功能困难：如果要实现“群发消息”，每个User都需要遍历整个列表。如果要实现“禁止某个用户发言”，需要修改所有其他User的逻辑来判断是否应该接收消息。
  2. 依赖关系复杂：User之间直接引用，形成网状结构。任何一个User的接口变动，都可能影响到所有引用了它的其他User。
  3. 复用性差：User类因为包含了太多与其他User交互的逻辑，很难被剥离出来单独复用到其他不涉及聊天功能的模块中。
  4. 测试困难：要单元测试一个User的sendMessage，你必须为其构造和注入所有相关的User对象，测试环境搭建复杂。

2.2 中介者登场：引入聊天服务器

现在我们引入中介者模式，创建一个ChatServer（中介者）。每个User（同事对象）只认识这个ChatServer，所有消息的发送、接收、广播、过滤逻辑都集中在ChatServer中。

// 前置声明 class ChatServer; // 同事类基类或接口 class ChatUser { public: virtual ~ChatUser() = default; virtual void receive(const std::string& msg, const std::string& from) = 0; virtual std::string getName() const = 0; void setMediator(ChatServer* med) { mediator_ = med; } protected: ChatServer* mediator_ = nullptr; }; // 具体同事类 class User : public ChatUser { public: User(const std::string& name) : name_(name) {} void send(const std::string& msg, const std::string& toUser); void broadcast(const std::string& msg); void receive(const std::string& msg, const std::string& from) override { std::cout << "[" << name_ << "]'s screen: Message from " << from << ": " << msg << std::endl; } std::string getName() const override { return name_; } private: std::string name_; }; // 中介者接口 class ChatMediator { public: virtual ~ChatMediator() = default; virtual void sendMessage(const std::string& msg, const std::string& from, const std::string& to) = 0; virtual void broadcastMessage(const std::string& msg, const std::string& from) = 0; virtual void registerUser(ChatUser* user) = 0; }; // 具体中介者 class ChatServer : public ChatMediator { public: void registerUser(ChatUser* user) override { users_[user->getName()] = user; user->setMediator(this); } void sendMessage(const std::string& msg, const std::string& from, const std::string& to) override { auto it = users_.find(to); if (it != users_.end()) { it->second->receive(msg, from); } else { std::cout << "Server: User '" << to << "' not found." << std::endl; } } void broadcastMessage(const std::string& msg, const std::string& from) override { for (auto& pair : users_) { if (pair.first != from) { // 不发送给自己 pair.second->receive(msg, from); } } } private: std::unordered_map<std::string, ChatUser*> users_; }; // User的方法实现（需要中介者） void User::send(const std::string& msg, const std::string& toUser) { if (mediator_) { mediator_->sendMessage(msg, this->getName(), toUser); } } void User::broadcast(const std::string& msg) { if (mediator_) { mediator_->broadcastMessage(msg, this->getName()); } }

经过这番改造，架构发生了根本变化：

  • User类变得干净：它只负责表达自己（名字）和实现如何显示消息（receive）。它不知道其他任何User的存在。
  • 交互逻辑集中化：所有路由逻辑（点对点发送、广播）、业务规则（能否发送、是否过滤）都集中在ChatServer中。要添加“敏感词过滤”或“私聊权限检查”，只需修改ChatServer的sendMessage方法，User类完全不用动。
  • 依赖简化：从网状依赖变为星型依赖。User只依赖ChatServer，User之间零依赖。这符合“迪米特法则”（最少知识原则）。

注意：上面示例中，User持有mediator_指针是一个常见实现，但需要小心生命周期管理。通常中介者（如ChatServer）的生命周期应长于或等于所有同事对象。在实际项目中，更安全的做法可能是使用std::weak_ptr或依赖注入容器来管理这种关系，避免悬空指针。

3. 模式结构深度解析与C++实现要点

理解了核心思想，我们拆开看看中介者模式的标准化结构，并探讨在C++中实现时的关键细节。经典的中介者模式包含四个角色：

  1. Mediator（中介者接口）：定义同事对象与中介者通信的接口，通常是一个notify或send方法。
  2. ConcreteMediator（具体中介者）：实现中介者接口，协调各同事对象。它知晓所有具体的同事类，并负责具体的业务逻辑转发与协调。
  3. Colleague（同事类接口/基类）：定义同事对象的接口。通常包含一个指向中介者的引用（指针或引用），用于与中介者通信。
  4. ConcreteColleague（具体同事类）：实现同事类接口。每个具体同事对象只知道中介者，当需要与其他同事通信时，通过中介者转发。

3.1 经典结构实现与内存管理

参考网络资料中常见的示例，我们用C++实现一个更通用的版本，并重点关注资源管理。

#include <iostream> #include <string> #include <memory> #include <vector> // 前置声明 class BaseComponent; // 1. 中介者接口 class Mediator { public: virtual ~Mediator() = default; virtual void notify(const std::shared_ptr<BaseComponent>& sender, const std::string& event) const = 0; }; // 2. 同事基类 class BaseComponent : public std::enable_shared_from_this<BaseComponent> { public: virtual ~BaseComponent() = default; void set_mediator(const std::shared_ptr<Mediator>& mediator) { mediator_ = mediator; } protected: std::shared_ptr<Mediator> mediator_; }; // 3. 具体同事类 A class ConcreteComponentA : public BaseComponent { public: void operationA() { std::cout << "ConcreteComponentA executes operationA.\n"; if (auto med = mediator_.lock()) { // 使用weak_ptr避免循环引用 med->notify(shared_from_this(), "EventA"); } } void reactOnEventB() { std::cout << "ConcreteComponentA reacts to EventB.\n"; } }; // 4. 具体同事类 B class ConcreteComponentB : public BaseComponent { public: void operationB() { std::cout << "ConcreteComponentB executes operationB.\n"; if (auto med = mediator_.lock()) { med->notify(shared_from_this(), "EventB"); } } void reactOnEventA() { std::cout << "ConcreteComponentB reacts to EventA.\n"; } }; // 5. 具体中介者 class ConcreteMediator : public Mediator, public std::enable_shared_from_this<ConcreteMediator> { public: ConcreteMediator(const std::shared_ptr<ConcreteComponentA>& compA, const std::shared_ptr<ConcreteComponentB>& compB) : componentA_(compA), componentB_(compB) { // 建立双向关联 componentA_->set_mediator(shared_from_this()); componentB_->set_mediator(shared_from_this()); } void notify(const std::shared_ptr<BaseComponent>& sender, const std::string& event) const override { // 根据发送者和事件类型，协调其他组件的行为 if (event == "EventA") { std::cout << "Mediator: Reacting to EventA from ComponentA, triggering ComponentB...\n"; componentB_->reactOnEventA(); } else if (event == "EventB") { std::cout << "Mediator: Reacting to EventB from ComponentB, triggering ComponentA...\n"; componentA_->reactOnEventB(); } } private: std::shared_ptr<ConcreteComponentA> componentA_; std::shared_ptr<ConcreteComponentB> componentB_; }; int main() { // 使用智能指针管理生命周期 auto compA = std::make_shared<ConcreteComponentA>(); auto compB = std::make_shared<ConcreteComponentB>(); auto mediator = std::make_shared<ConcreteMediator>(compA, compB); // 注意：这里存在循环引用！compA和compB通过shared_ptr持有mediator， // mediator也通过shared_ptr持有compA和compB。需要打破循环。 // 更安全的做法：同事类持有mediator的weak_ptr。 compA->operationA(); std::cout << "---\n"; compB->operationB(); return 0; }

实现要点与陷阱：

  1. 循环引用问题：这是C++实现中介者模式最常见的坑。如上面代码注释所示，如果同事类和中介者互相用std::shared_ptr持有对方，就会形成循环引用，导致内存泄漏。标准解决方案是：同事类持有中介者的std::weak_ptr，中介者可以持有同事类的std::shared_ptr（因为中介者通常管理着同事对象的生命周期或视图）。上面示例中BaseComponent的mediator_应改为std::weak_ptr<Mediator>，调用时使用lock()检查有效性。

  2. 中介者接口设计：notify方法的参数设计至关重要。通常需要传递“发送者”和“事件标识”。事件标识可以用枚举、字符串或更复杂的事件对象。为了灵活性，我倾向于使用一个简单的事件结构体：

    struct MediatorEvent { std::string type; std::any data; // C++17，或使用自定义的variant/union // ... 其他上下文信息 }; virtual void notify(BaseComponent* sender, const MediatorEvent& event) = 0;

  3. 同事类的通用性：为了让中介者能处理不同类型的同事，通常需要让所有同事类继承自一个公共基类（如BaseComponent），或者使用模板技术。公共基类方法更常见，但会引入一定的类型擦除。如果同事类型差异极大，可以考虑让中介者接口支持多种重载的notify方法。

3.2 中介者模式的变体与实践

在实际项目中，纯粹的中介者模式可能会显得笨重。下面介绍两种实用的变体：

变体一：事件总线（Event Bus）—— 更松耦合的中介者事件总线可以看作是一个全局的、支持发布-订阅模式的中介者。同事对象（订阅者）向总线注册对特定事件类型的兴趣，其他同事（发布者）触发事件时，总线负责将事件分发给所有订阅者。这种方式完全解耦了发布者和订阅者，它们甚至不需要知道彼此的存在。

#include <functional> #include <map> #include <vector> #include <string> #include <memory> class EventBus { public: using Handler = std::function<void(const std::string& eventData)>; void subscribe(const std::string& eventType, Handler handler) { subscribers_[eventType].push_back(handler); } void publish(const std::string& eventType, const std::string& eventData) { auto it = subscribers_.find(eventType); if (it != subscribers_.end()) { for (auto& handler : it->second) { handler(eventData); } } } private: std::unordered_map<std::string, std::vector<Handler>> subscribers_; }; // 使用 EventBus bus; bus.subscribe("ButtonClicked", [](auto data){ std::cout << "Handler1: " << data << std::endl; }); bus.subscribe("ButtonClicked", [](auto data){ std::cout << "Handler2: " << data << std::endl; }); bus.publish("ButtonClicked", "SubmitButton");

变体二：控制器（Controller）—— MVC中的中介者在MVC（Model-View-Controller）架构中，Controller就是典型的中介者。View（用户界面）和Model（业务数据/逻辑）不直接通信。View将用户输入（如按钮点击）传递给Controller，Controller决定如何更新Model，并可能通知View更新显示。这种模式在Qt、MFC、WinForms等GUI框架中非常普遍。

// 简化的MVC示例 class DataModel { // Model public: void setData(int d) { data_ = d; /* 可能触发计算 */ } int getData() const { return data_; } private: int data_ = 0; }; class MainWindow { // View public: void updateDisplay(int value) { std::cout << "View updated: " << value << std::endl; } void onUserInput(int input) { /* 将输入事件转发给Controller */ } }; class AppController { // Controller (Mediator) public: AppController(DataModel* m, MainWindow* v) : model_(m), view_(v) {} void handleInput(int newValue) { model_->setData(newValue); view_->updateDisplay(model_->getData()); // 这里还可以协调其他Model或View } private: DataModel* model_; MainWindow* view_; };

4. 实战案例：基于中介者模式重构一个订单处理系统

让我们看一个更贴近业务的例子。假设有一个简单的订单处理模块，涉及Order（订单）、Inventory（库存）、PaymentProcessor（支付处理器）、NotificationService（通知服务）四个类。初始版本中，它们直接互相调用：

// 紧耦合的旧代码 class Order { void checkout() { if (inventory_->reserve(items_)) { if (paymentProcessor_->charge(total_)) { notificationService_->sendEmail(user_, "Order Confirmed"); status_ = CONFIRMED; } else { inventory_->release(items_); notificationService_->sendEmail(user_, "Payment Failed"); } } else { notificationService_->sendEmail(user_, "Out of Stock"); } } private: Inventory* inventory_; PaymentProcessor* paymentProcessor_; NotificationService* notificationService_; // ... 其他字段 };

这段代码的问题很明显：Order类承担了过多的协调职责，并且严重依赖三个外部服务。任何服务的接口变化或业务流程调整（比如增加一个“风控检查”步骤）都需要修改Order::checkout方法，违反了单一职责原则和开闭原则。

使用中介者模式重构：

我们引入一个OrderMediator来协调整个流程。

#include <iostream> #include <string> #include <memory> // 1. 同事类接口（可选，这里为了清晰而定义） class OrderComponent { public: virtual ~OrderComponent() = default; virtual void setMediator(class OrderMediator* mediator) = 0; }; // 2. 具体同事类 class Inventory : public OrderComponent { public: void setMediator(OrderMediator* mediator) override { mediator_ = mediator; } bool reserveItems(const std::vector<std::string>& items) { std::cout << "Inventory: Attempting to reserve items...\n"; // 模拟库存检查 bool success = !items.empty(); // 简化逻辑 if (success) { std::cout << "Inventory: Items reserved successfully.\n"; } else { std::cout << "Inventory: Reservation failed.\n"; } return success; } void releaseItems(const std::vector<std::string>& items) { std::cout << "Inventory: Releasing reserved items.\n"; } private: OrderMediator* mediator_ = nullptr; }; class PaymentProcessor : public OrderComponent { public: void setMediator(OrderMediator* mediator) override { mediator_ = mediator; } bool processPayment(double amount) { std::cout << "PaymentProcessor: Processing payment of $" << amount << "...\n"; // 模拟支付 bool success = amount > 0; if (success) { std::cout << "PaymentProcessor: Payment successful.\n"; } else { std::cout << "PaymentProcessor: Payment failed.\n"; } return success; } private: OrderMediator* mediator_ = nullptr; }; class NotificationService : public OrderComponent { public: void setMediator(OrderMediator* mediator) override { mediator_ = mediator; } void sendEmail(const std::string& user, const std::string& message) { std::cout << "NotificationService: Sending email to " << user << ": " << message << "\n"; } private: OrderMediator* mediator_ = nullptr; }; class Order : public OrderComponent { public: Order(const std::string& user, const std::vector<std::string>& items, double total) : user_(user), items_(items), total_(total) {} void setMediator(OrderMediator* mediator) override { mediator_ = mediator; } void checkout() { std::cout << "Order: Checkout initiated for user " << user_ << ".\n"; if (mediator_) { mediator_->placeOrder(this); } } const std::string& getUser() const { return user_; } const std::vector<std::string>& getItems() const { return items_; } double getTotal() const { return total_; } void setStatus(const std::string& status) { status_ = status; std::cout << "Order: Status updated to '" << status_ << "'.\n"; } private: std::string user_; std::vector<std::string> items_; double total_; std::string status_ = "PENDING"; OrderMediator* mediator_ = nullptr; }; // 3. 中介者 class OrderMediator { public: OrderMediator(std::shared_ptr<Inventory> inv, std::shared_ptr<PaymentProcessor> pay, std::shared_ptr<NotificationService> notif) : inventory_(std::move(inv)), paymentProcessor_(std::move(pay)), notificationService_(std::move(notif)) { // 建立关联 inventory_->setMediator(this); paymentProcessor_->setMediator(this); notificationService_->setMediator(this); } void registerOrder(Order* order) { order->setMediator(this); } void placeOrder(Order* order) { std::cout << "\n--- Mediator coordinating order flow ---\n"; // 1. 检查库存 if (!inventory_->reserveItems(order->getItems())) { notificationService_->sendEmail(order->getUser(), "Sorry, some items are out of stock."); order->setStatus("FAILED_STOCK"); return; } // 2. 处理支付 if (!paymentProcessor_->processPayment(order->getTotal())) { inventory_->releaseItems(order->getItems()); notificationService_->sendEmail(order->getUser(), "Payment failed. Please check your payment method."); order->setStatus("FAILED_PAYMENT"); return; } // 3. 成功 notificationService_->sendEmail(order->getUser(), "Your order has been confirmed! Thank you."); order->setStatus("CONFIRMED"); std::cout << "--- Order flow completed successfully ---\n\n"; } private: std::shared_ptr<Inventory> inventory_; std::shared_ptr<PaymentProcessor> paymentProcessor_; std::shared_ptr<NotificationService> notificationService_; }; // 客户端代码 int main() { auto inventory = std::make_shared<Inventory>(); auto payment = std::make_shared<PaymentProcessor>(); auto notifier = std::make_shared<NotificationService>(); auto mediator = std::make_shared<OrderMediator>(inventory, payment, notifier); Order order1("alice@example.com", {"item1", "item2"}, 99.99); mediator->registerOrder(&order1); order1.checkout(); return 0; }

重构带来的好处：

  1. Order类职责单一：现在它只负责保存订单数据和发起checkout请求，复杂的协调逻辑被剥离。
  2. 业务流程集中管理：所有订单处理逻辑都在OrderMediator::placeOrder中，清晰可见。要增加风控步骤，只需在此方法中插入一行，调用风控组件的接口。
  3. 组件可复用性增强：Inventory、PaymentProcessor等组件不再被Order直接依赖，可以更容易地被其他模块（如换货流程、订阅服务）复用。
  4. 易于测试：现在可以单独测试OrderMediator的业务逻辑，通过Mock对象注入各个服务，而不需要构建整个复杂的系统。

5. 中介者模式的优缺点与适用场景判断

没有一种设计模式是银弹，中介者模式也不例外。用了它，你可能获得了解耦和集中控制的好处，但也可能引入新的问题。

5.1 优点

  • 减少类间耦合：将多对多的交互转化为一对多的交互，这是它最大的价值。系统更容易理解和维护。
  • 集中控制交互：将交互逻辑集中在一个中介者中，使得这些逻辑更容易被理解和修改。对于复杂的交互规则，这比分散在各个类中要好管理得多。
  • 简化对象协议：同事类只需与中介者通信，无需维护与其他同事类通信的复杂协议。
  • 有利于各组件复用：由于同事类之间没有直接引用，它们可以更容易地在不同上下文中独立复用。

5.2 缺点与风险

  • 中介者可能演变为“上帝对象”：这是中介者模式最常被诟病的一点。如果所有交互逻辑都塞进中介者，它会变得极其庞大、复杂、难以维护，最终成为一个新的单点故障和修改瓶颈。
  • 性能微开销：多了一层转发，会引入轻微的性能开销。对于性能极其敏感的实时系统，需要评估。
  • 增加了系统中类的数量：多了一个中介者接口和至少一个具体中介者类。

5.3 何时使用？—— 几个关键信号

根据我的经验，当你出现以下迹象时，可以考虑引入中介者模式：

  1. “蜘蛛网”依赖：一组对象之间的通信关系复杂，导致每个对象都与其他多个对象紧密耦合，依赖图难以理解。
  2. 复用受阻：你想复用一个类，但因为它在代码中直接引用了太多其他特定环境的类而无法轻易剥离。
  3. 行为分散：对象之间的交互逻辑分散在许多类中，导致修改一个交互规则需要改动多个地方。
  4. 组件需要定制化交互：你希望在不改变组件本身的情况下，通过更换不同的中介者来改变组件间的交互行为（这有点像策略模式用于交互逻辑）。

典型应用场景：

  • GUI框架和组件通信：按钮、文本框、列表框等控件通过窗口（中介者）来协调。例如，点击“浏览”按钮（触发事件给中介者），中介者打开文件对话框，然后将选择的文件路径更新到文本框中。
  • 聊天应用/消息系统：如前所述，用户不直接对话，通过服务器中转。
  • 工作流或业务流程引擎：多个服务或处理器（同事）通过一个工作流引擎（中介者）来串联，引擎决定执行顺序和条件分支。
  • 游戏开发：游戏中的单位（Unit）、建筑（Building）、资源（Resource）可能通过一个游戏逻辑控制器（GameController）来交互，而不是直接互相引用。

5.4 注意事项与最佳实践

  1. 防止中介者膨胀：不要把所有逻辑都扔进中介者。如果中介者的notify方法变成了一个巨大的switch-case或if-else链，说明它承担了太多职责。这时可以考虑：
    • 拆分中介者：根据业务领域，拆分成多个更细粒度的中介者（如OrderMediator,UserMediator）。
    • 引入职责链或命令模式：将一些处理逻辑从中介者中抽离，形成独立的处理链或命令对象，中介者只负责路由。
  2. 明确生命周期：在C++中，要格外小心中介者和同事对象之间的生命周期管理。通常，中介者的生命周期应该最长。使用智能指针（shared_ptr/weak_ptr）并仔细设计所有权关系，避免循环引用和悬空指针。
  3. 考虑线程安全：如果同事对象可能在不同线程中被调用，那么中介者的notify方法必须是线程安全的。你可能需要引入锁（如std::mutex）或使用线程安全的数据结构，但这会增加复杂度。在设计初期就要想清楚并发模型。
  4. 不要滥用：如果对象之间的交互本来就很简单的（比如只有两个对象单向通信），强行引入中介者就是过度设计，只会增加不必要的抽象层。

6. 常见问题、调试技巧与替代方案

在实际使用中，你可能会遇到一些典型问题。

Q1: 中介者模式似乎和观察者模式很像，它们有什么区别？这是一个非常好的问题。两者都用于处理对象间的通信，但方向不同：

  • 观察者模式：定义了一种一对多的依赖关系。当一个对象（主题）状态改变时，所有依赖它的对象（观察者）都会得到通知并自动更新。观察者模式更侧重于状态的同步和广播。
  • 中介者模式：定义了一个封装一组对象交互的对象。对象之间不直接通信，而是通过中介者间接通信。中介者模式更侧重于协调复杂的交互逻辑，它知道所有同事的细节，并可能根据复杂的业务规则来决定如何转发或处理消息。
    • 简单比喻：观察者模式像是邮件列表，你订阅了，有消息就发给你。中介者模式像是客服中心，你有问题打给客服，客服再根据你的问题类型转接给相应的部门或给出解决方案。

Q2: 中介者模式中的同事类需要知道中介者，这不算耦合吗？算，但这是一种更可控、更松散的耦合。从“网状耦合”（每个对象依赖多个其他对象）变成了“星型耦合”（每个对象只依赖一个中介者）。这种耦合是必要的，也是模式设计的一部分。我们可以通过依赖注入来管理这种耦合，使其易于测试和替换。

Q3: 调试中介者模式时，问题不好定位，因为调用链路变长了。确实，错误可能发生在同事对象、中介者转发或事件处理中。我的调试技巧是：

  1. 日志增强：在中介者的关键方法（如notify）入口和出口添加详细的日志，打印发送者、事件类型、处理结果。这能帮你看清事件流转的全路径。
  2. 简化重现：尝试构造一个最小化的、能复现问题的同事对象集合和事件序列，隔离无关因素。
  3. 检查中介者状态：确保中介者正确持有了所有相关同事对象的引用，并且没有空指针或失效的弱引用。
  4. 使用调试器条件断点：在notify方法中针对特定发送者或事件类型设置条件断点。

Q4: 除了中介者模式，还有哪些模式可以解耦对象交互？

  • 观察者模式：适用于一个对象状态变化需要通知多个其他对象的场景，解耦了主题和观察者。
  • 命令模式：将请求封装为对象，从而允许你用不同的请求对客户进行参数化、队列化请求、支持可撤销的操作等。它可以用来解耦请求发送者和接收者。
  • 职责链模式：让多个对象都有机会处理请求，从而避免请求发送者和接收者之间的耦合。将这些对象连成一条链，并沿着这条链传递请求。
  • 发布-订阅模式：比观察者模式更解耦，发布者和订阅者完全不知道对方的存在，通过一个消息代理（Broker）通信。这是事件总线的理论基础。

选择哪种模式，取决于你的具体场景：是需要复杂的协调逻辑（中介者），还是简单的状态同步（观察者），或是处理请求的链条（职责链）。

我个人在项目中的体会是，中介者模式是一剂“猛药”，用于治疗“高度耦合”的痼疾。用对了地方，代码结构会立刻清晰很多；用错了或者用过头，就会制造出一个难以维护的“大泥球”。关键是要时刻审视中介者类的体积和职责，如果它开始变得臃肿，就是时候考虑重构了——也许那个庞大的中介者本身，就可以用其他模式（如策略、状态、职责链）来进一步分解。设计模式从来不是孤立使用的，将它们组合起来，才能应对真实世界的复杂软件设计。