C++中介者模式实现方法解析

中介者模式的核心优势是降低对象间的耦合度，通过引入一个中心化的中介者协调多个对象之间的交互。1. 它将原本复杂的网状依赖关系转换为多对一的依赖结构，每个对象仅需知道中介者而无需了解其他对象；2. 所有交互逻辑集中于中介者，提升了系统的可维护性和可复用性；3. 通过解耦对象间直接通信，使得对象可以独立变化和复用，增强了扩展性。

中介者模式在C++中实现，核心在于引入一个中心化的“中介”对象，它负责协调和管理一组对象（通常称为“同事”或“参与者”）之间的交互。这样一来，原本复杂的、网状的直接依赖关系就被解耦，每个对象只需知道中介者，而无需了解其他对象的具体实现或如何与它们通信。这大大简化了系统结构，提高了代码的可维护性和复用性。

解决方案

在C++中实现中介者模式，通常需要定义几个关键角色：抽象中介者、具体中介者、抽象同事和具体同事。

首先，我们定义抽象中介者（Mediator）接口，它声明了同事之间通信的方法。接着是抽象同事（Colleague）接口，每个同事都会持有一个指向其所属中介者的引用，并通过这个引用来发送消息。

// 抽象中介者接口
class Colleague; // 前置声明，避免循环依赖

class Mediator {
public:
    virtual ~Mediator() = default;
    virtual void notify(Colleague* sender, const std::string& event) const = 0;
};

// 抽象同事接口
class Colleague {
protected:
    Mediator* mediator_; // 持有中介者的引用

public:
    Colleague(Mediator* mediator = nullptr) : mediator_(mediator) {}
    virtual ~Colleague() = default;

    void setMediator(Mediator* mediator) {
        this->mediator_ = mediator;
    }
};

然后，我们实现具体的同事类。这些具体同事不再直接与其他同事交互，而是通过它们持有的中介者引用来发送消息。

#include 
#include 
#include 
#include  // For std::shared_ptr

// 具体同事A
class ConcreteColleagueA : public Colleague {
public:
    ConcreteColleagueA(Mediator* mediator = nullptr) : Colleague(mediator) {}

    void send(const std::string& message) {
        std::cout << "ColleagueA sends: " << message << std::endl;
        if (mediator_) {
            mediator_->notify(this, message);
        }
    }

    void receive(const std::string& message) {
        std::cout << "ColleagueA receives: " << message << std::endl;
    }
};

// 具体同事B
class ConcreteColleagueB : public Colleague {
public:
    ConcreteColleagueB(Mediator* mediator = nullptr) : Colleague(mediator) {}

    void send(const std::string& message) {
        std::cout << "ColleagueB sends: " << message << std::endl;
        if (mediator_) {
            mediator_->notify(this, message);
        }
    }

    void receive(const std::string& message) {
        std::cout << "ColleagueB receives: " << message << std::endl;
    }
};

最后，实现具体中介者（ConcreteMediator）。这是模式的核心，它了解所有具体同事，并负责协调它们之间的通信。当一个同事通过中介者发送消息时，中介者会根据业务逻辑决定将消息转发给哪些其他同事。

// 具体中介者
class ConcreteMediator : public Mediator {
private:
    // 使用智能指针管理同事对象生命周期，或根据实际情况决定所有权
    std::shared_ptr colleagueA_;
    std::shared_ptr colleagueB_;

public:
    ConcreteMediator(std::shared_ptr a, std::shared_ptr b)
        : colleagueA_(a), colleagueB_(b) {
        // 让同事知道它们的中介者
        if (colleagueA_) colleagueA_->setMediator(this);
        if (colleagueB_) colleagueB_->setMediator(this);
    }

    void notify(Colleague* sender, const std::string& event) const override {
        if (sender == colleagueA_.get()) {
            std::cout << "Mediator received message from ColleagueA. Processing..." << std::endl;
            // 假设ColleagueA发送消息后，需要ColleagueB做出响应
            if (colleagueB_) {
                colleagueB_->receive("Response from Mediator to B for event: " + event);
            }
        } else if (sender == colleagueB_.get()) {
            std::cout << "Mediator received message from ColleagueB. Processing..." << std::endl;
            // 假设ColleagueB发送消息后，需要ColleagueA做出响应
            if (colleagueA_) {
                colleagueA_->receive("Response from Mediator to A for event: " + event);
            }
        }
        // 可以在这里添加更多复杂的逻辑，根据事件类型或发送者决定如何转发
    }
};

使用示例：

int main() {
    // 创建同事对象
    auto c1 = std::make_shared();
    auto c2 = std::make_shared();

    // 创建中介者，并关联同事
    // 注意：这里中介者持有同事的shared_ptr，意味着中介者负责同事的生命周期
    // 实际项目中可能需要更复杂的生命周期管理策略
    auto mediator = std::make_shared(c1, c2);

    // 同事通过中介者发送消息
    c1->send("I need something from B!");
    std::cout << "---" << std::endl;
    c2->send("I'm ready to respond.");

    return 0;
}

这段代码展示了中介者模式的基本骨架。ConcreteColleagueA和ConcreteColleagueB不再直接调用彼此的方法，它们只知道自己的中介者。所有通信都通过ConcreteMediator进行转发和协调。

中介者模式的核心优势是什么？它如何降低耦合度？

在我看来，中介者模式最迷人的地方在于它如何巧妙地“抽离”了对象间的直接对话。想想看，如果你的系统里有十几个对象，它们之间需要互相协作，比如一个按钮点击了要更新文本框，文本框内容变了要校验，校验结果又影响另一个下拉菜单的启用状态……如果让这些对象直接互相引用和调用，那简直是一场灾难。每个对象都需要知道其他对象的接口，维护它们之间的引用，一旦某个对象的行为改变，可能就要牵一发动全身，修改一大堆地方。这就像一个大型会议室里，每个人都直接对其他人喊话，场面必然混乱不堪。

中介者模式就像是引入了一个“主持人”或者“中央调度员”。所有的交流都必须通过这个主持人。比如，按钮不再直接告诉文本框“我被点击了”，而是告诉主持人“我被点击了”。主持人听到后，再根据预设的规则，告诉文本框“你该更新了”。这样一来，按钮和文本框之间就完全不认识对方了，它们只认识主持人。这种模式将多对多的直接依赖关系，转化为了多对一（所有同事都依赖中介者）的依赖关系。

这种转变带来的好处是显而易见的：

1. 降低了耦合度： 这是最核心的优势。每个同事对象只需要知道中介者的接口，而不需要知道其他同事的接口。这意味着你可以独立地修改或替换任何一个同事，只要它与中介者的交互方式不变，就不会影响到其他同事。
2. 集中化控制逻辑： 所有的交互逻辑都集中在中介者内部，这使得管理和维护这些复杂的交互变得容易。当需要改变对象间的协作方式时，你只需要修改中介者，而不是散落在各个同事对象中的代码。
3. 提高了可复用性： 由于同事对象不再直接依赖于其他特定同事，它们变得更加独立。你可以更容易地将这些同事对象在不同的场景或项目中复用，因为它们不再“绑定”于某个特定的协作环境。

当然，这种“主持人”模式也有其代价，但对于复杂交互的系统来说，这种解耦带来的结构清晰和维护便利性，绝对是值得的。

在C++中实现中介者模式时，有哪些常见的陷阱或挑战？

在C++中实践中介者模式，虽然其设计思想很优雅，但具体落地时，确实会遇到一些让人头疼的细节问题。这不像写个Hello World那么简单，很多时候，一个不小心，就可能让模式的优势大打折扣。

一个最常见的挑战就是“中介者膨胀”，或者说，中介者变成了所谓的“上帝对象”（God Object）。当系统中所有的交互逻辑都一股脑地塞进中介者里，它就会变得越来越庞大、越来越复杂，最终成为一个难以理解和维护的巨石。它的职责变得模糊，包含了太多的业务逻辑，这反而违背了我们最初解耦的初衷。解决这个问题，需要我们在设计中介者时，严格控制其职责范围，只处理同事之间的协调逻辑，而将具体的业务逻辑保留在同事对象内部。如果中介者真的变得过于复杂，可能需要考虑将其中一部分职责拆分到更小的、更专业的子中介者中，或者结合其他设计模式（比如策略模式）来管理中介者内部的复杂行为。

另一个不容忽视的问题是生命周期管理。在C++中，指针的使用总是伴随着所有权和生命周期的问题。中介者通常需要持有对其同事对象的引用（或指针），而同事对象也需要持有对其所属中介者的引用。这种双向引用很容易导致循环引用，尤其是在使用std::shared_ptr时。如果处理不当，可能导致内存泄漏。通常的解决方案是，让中介者持有同事的std::shared_ptr（表明中介者拥有同事），而同事则持有中介者的std::weak_ptr或原始指针（raw pointer），并确保在使用前检查其有效性。原始指针虽然简单，但要求我们手动管理好对象的生命周期，确保中介者在同事销毁之前存在，或者在同事销毁时能通知中介者移除其引用。

此外，调试复杂性也是一个潜在的挑战。当对象间的直接通信被中介者“隐藏”起来时，调试起来可能会稍微麻烦一些。你不能简单地跟踪一个直接的方法调用链，而是需要深入到中介者内部，理解它是如何根据事件类型和发送者来转发消息的。这要求中介者的逻辑必须清晰、可预测，并且最好有良好的日志记录机制，以便在出现问题时能够追踪通信路径。

最后，虽然不是一个“陷阱”，但需要注意的是性能开销。引入中介者会增加一层间接性。对于极度追求性能、通信频率非常高的场景，这种额外的函数调用和查找开销，虽然通常微乎其微，但也可能成为一个考虑因素。不过，在绝大多数业务应用中，这种性能影响几乎可以忽略不计，解耦带来的收益远大于此。

中介者模式在实际项目中有哪些典型应用场景？

中介者模式并非随处可见，但一旦遇到它能大放异彩的场景，你会发现它简直是解决复杂交互的“银弹”。在我自己的开发经历中，它常常出现在那些需要大量组件协同工作，但又不希望它们彼此直接“认识”的场合。

最经典的莫过于图形用户界面（GUI）框架。想象一个复杂的对话框，里面有按钮、文本框、下拉列表、复选框等等。当用户点击一个按钮时，可能需要禁用某个文本框，同时根据文本框的内容更新下拉列表的选项，甚至还要触发一个后台的数据校验。如果让这些UI组件直接互相调用方法，那代码会变得一团糟，而且每个组件都难以独立测试和复用。这时，中介者模式就完美契合了。我们可以设计一个“对话框控制器”作为中介者，所有的UI组件都只向这个控制器报告自己的事件（比如“我被点击了”、“我的文本改变了”），然后控制器根据这些事件，协调其他UI组件做出相应的响应。这样，每个UI组件都变得“傻瓜化”和可复用，它们只负责自己的渲染和事件报告，而复杂的交互逻辑则全部集中在控制器中。

另一个非常直观的应用是聊天室系统。在一个聊天室里，多个用户（或客户端）需要互相发送消息。如果每个用户都直接向其他所有用户发送消息，那管理起来会非常困难，而且消息广播的逻辑会散落在各个客户端中。中介者模式在这里可以完美地体现在“聊天服务器”或者“聊天室对象”上。每个用户只将消息发送给这个聊天室中介者，然后中介者负责将消息转发给聊天室内的其他所有用户。用户之间不再有直接的连接，所有的通信都通过中介者进行，这使得消息的过滤、广播、用户上下线管理等功能都变得集中和易于实现。

再比如，在一些复杂业务流程的编排中，中介者模式也很有用。设想一个订单处理系统，它可能涉及到库存管理、支付系统、物流系统、用户通知系统等多个独立模块。当一个订单创建后，这些模块需要协同工作：检查库存、扣款、安排发货、发送确认邮件等。如果让这些模块直接互相调用，它们的耦合度会非常高。我们可以引入一个“订单处理器”作为中介者，它负责接收订单创建事件，然后协调各个子系统完成各自的任务。例如，订单处理器通知库存系统减少库存，库存系统完成后通知处理器，处理器再通知支付系统扣款，以此类推。每个模块都只与订单处理器交互，从而实现了模块间的解耦。

总的来说，只要你发现系统中存在大量对象之间复杂的、网状的直接交互，并且这种交互导致了高耦合度和难以维护的局面，那么中介者模式就值得你认真考虑。它能帮助你将混乱的交互逻辑梳理清晰，提升系统的整体可维护性和扩展性。