c++如何实现观察者模式_c++消息通知机制编写【进阶】

1次阅读

c++ 如何实现观察者模式_c++ 消息通知机制编写【进阶】

怎么用 std::function 替代继承,避免虚函数开销?

纯虚基类 Observer 虽然符合设计模式教科书,但每次 update() 调用都带虚表跳转,在高频通知场景(比如实时行情推送、传感器采样)下有可测的性能损耗。改用 std::function 是更轻量的选择。

  • 被观察者内部用 std::vector<:function>> callbacks_</:function> 存回调,而不是 Observer* 指针
  • 注册时直接传 lambda:subject.on_update([]{ std::cout
  • 注意捕获变量生命周期:lambda 若捕获局部对象,必须确保该对象在通知发生时仍有效;建议只捕获 this 或静态 / 全局数据
  • 不支持运行时多态,但绝大多数业务场景里你根本不需要“动态切换观察者类型”,只需要“执行某段逻辑”

为什么 weak_ptr 比裸指针安全得多?

裸指针版本里,如果某个 Observer 对象提前析构,而 Subject 还没调用 detach(),后续 notify() 就会触发野指针访问——崩溃不一定立刻出现,可能隔几轮才复现,极难定位。

  • 把观察者改为继承 std::enable_shared_from_this,注册时存 std::weak_ptr<observer></observer>
  • notify() 中遍历前先 lock(),跳过已失效的项:if (auto obs = wp.lock()) obs->update();
  • 不用手动 detach(),析构自动失效,彻底消除悬空风险
  • 代价是每次通知多一次原子引用计数操作,但比 crash 便宜多了

notify() 在多线程里为什么不能直接遍历?

常见错误是让一个线程调用 setState(),另一个线程同时调用 attach()detach(),导致 observers 容器迭代器失效或内存越界。

  • 最简方案:对整个通知过程加互斥锁,但会阻塞所有观察者执行,尤其当某个观察者做 I/O 或 sleep 时,拖慢整个链路
  • 进阶做法:用读写锁(如 std::shared_mutex),读多写少场景下提升并发度
  • 更稳的方案:把待通知列表在加锁区复制一份(auto snapshot = observers_),解锁后再遍历副本——观察者执行期间不影响新注册 / 注销
  • 别忘了:lambda 回调若跨线程执行,要自己保证其捕获对象的线程安全

要不要把状态数据传给 update()?传什么?

很多示例只传空参 update(),结果观察者只能靠 subject.getState() 主动拉取——这隐含耦合:观察者必须知道 subject 的接口,且可能重复构造临时对象。

立即学习 C++ 免费学习笔记(深入)”;

  • 推荐在通知时直接传递变化的关键数据,比如 void update(int new_price, timestamp_t ts)
  • 避免传大对象,优先传 const& 或移动语义(std::string&&
  • 若状态结构复杂,定义轻量通知结构体(如 struct PriceUpdate {int bid; int ask;};),比暴露整个 subject 更可控
  • 不要为了“通用”而设计万能 update(const std::any&)——类型擦除开销大,且失去编译期检查

真正麻烦的从来不是怎么写完 attach/notify,而是谁负责清理、谁持有所有权、通知时能不能重入、以及异常是否中断后续观察者执行——这些细节不画图、不跑压测,光看代码根本看不出问题。

text=ZqhQzanResources