大多数场景下不建议手写完整中介者类，应采用轻量级中心对象（如std::function+unordered_map）实现事件分发，通过前向声明与接口隔离解耦组件，qt中可用信号槽简化，dear imgui推荐单例eventbus，关键在于合理界定需中介的交互边界。
中介者模式在C++里到底要不要手写
大多数场景下，不建议从零手写完整中介者类。标准库没提供现成实现，但直接套用经典四要素（Mediator、Colleague抽象基类、具体同事类、具体中介者）容易过度设计。真实项目里，更常见的是用一个轻量级中心对象做事件分发或状态同步，比如用 std::function 存回调、用 std::unordered_map 管理订阅关系。
怎么让组件只依赖中介者接口，不互相include头文件
关键在前向声明 + 接口隔离。中介者头文件里只前向声明所有同事类型，同事头文件里只包含中介者的纯接口（如抽象基类或 struct），不包含具体实现。避免循环依赖的典型写法：
// Mediator.h
class ColleagueA;
class ColleagueB;
struct Mediator {
virtual void notify(ColleagueA* sender, int event) = 0;
virtual void notify(ColleagueB* sender, const std::string& msg) = 0;
};
同事类构造时传入 Mediator* 或 std::shared_ptr<mediator></mediator>，运行时绑定，编译期零耦合。
notify() 方法参数该用值传递还是引用/指针
取决于数据规模和是否需要修改原始对象：
- 小结构体（如
int、enum、短std::string）：值传递更安全，避免生命周期问题 - 大对象或需要中介者触发后处理的场景：用
const T&，但必须确保发送方对象存活时间长于通知处理周期 - 要让中介者能反向调用发送方方法：必须传指针（
T*）或智能指针，不能传引用（无法判空）
别用裸指针管理生命周期；若同事可能被提前销毁，中介者内部需配合 std::weak_ptr 做有效性检查，否则 notify() 调用会崩溃。
Qt 或 Dear ImGui 场景下怎么简化中介逻辑
已有信号槽机制时，中介者退化为纯业务协调层：
- Qt 中，把
Mediator设计成 QObject 派生类，用connect()绑定各组件信号到中介者槽函数，再由槽函数调用其他组件的 public slot —— 这比手动维护回调列表更可靠 - Dear ImGui 没有内置事件系统，推荐用单例
EventBus类，内部用std::vector<:function>></:function>存监听器，发布时遍历调用；注意帧内多次 publish 可能导致重复响应，加个bool processed标记位更稳妥
真正难的不是结构搭建，是界定“哪些交互必须走中介”——UI控件间颜色同步可以，但两个按钮共用一个计数器变量，直接共享变量反而更清晰。中介者不该成为兜底容器，而是明确边界的责任划分工具。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
