传统的观察者模式在现代c++++中显得笨拙，主要体现在类型耦合、生命周期管理困难和样板代码过多。1. 类型耦合：update方法签名固定，难以传递不同类型的数据，需大量接口或强制类型转换；2. 生命周期管理：主题持有裸指针，易导致悬空指针和程序崩溃；3. 样板代码：每个观察者都必须继承基类并实现虚函数，增加冗余代码。现代c++通过std::function、Lambda表达式和智能指针解决了这些问题，提升了灵活性与安全性。
C++中设计观察者模式，核心在于构建一种“一对多”的依赖关系，当一个对象的状态发生变化时，所有依赖于它的对象都会收到通知并自动更新。在现代C++的语境下，我们不再需要拘泥于传统的纯虚函数接口和裸指针，而是可以巧妙地利用C++11及更高版本提供的特性，如
std::function
、lambda表达式以及智能指针，来构建一个既安全又灵活的事件通知机制。这不仅能避免许多经典问题，比如内存泄漏或悬空指针，还能让代码写起来更优雅，更符合我们日常的思维习惯。
解决方案
设计现代C++观察者模式，我们通常会定义一个“主题”（Subject）类和一个“观察者”（Observer）概念。主题负责维护一个观察者列表，并在自身状态改变时通知它们。观察者则注册到主题上，并提供一个回调方法来接收通知。
核心设计思路：
立即学习“C++免费学习笔记（深入）”；
-
主题（Subject）类：
- 维护一个观察者列表。这个列表最好使用
std::vector<std::weak_ptr<CallbackType>>
，其中
CallbackType
可以是
std::function<void(Args...)>
，这样既能处理观察者的生命周期问题，又能保持回调的通用性。
- 提供
attach
（注册观察者）和
detach
（移除观察者）方法。
- 提供
notify
方法，遍历列表并调用每个观察者的回调。
- 维护一个观察者列表。这个列表最好使用
-
观察者（Observer）概念：
代码示例骨架：
#include <iostream> #include <vector> #include <functional> #include <memory> // For std::shared_ptr, std::weak_ptr #include <algorithm> // For std::remove_if // 定义一个通用的事件数据结构，或者直接传递可变参数 struct EventData { std::string message; int value; }; // Subject类 class Subject { public: // 回调类型，这里以EventData为例，也可以是void()或其它签名 using Callback = std::function<void(const EventData&)>; // 注册观察者：返回一个shared_ptr，方便外部管理其生命周期， // 内部存储weak_ptr，避免循环引用和悬空指针 std::shared_ptr<Callback> attach(Callback cb) { auto shared_cb = std::make_shared<Callback>(std::move(cb)); observers_.push_back(std::weak_ptr<Callback>(shared_cb)); // 清理无效的弱指针（已销毁的观察者） cleanup_observers(); return shared_cb; } // 移除观察者：通过比较shared_ptr的地址来移除 void detach(std::shared_ptr<Callback> cb_handle) { observers_.erase( std::remove_if(observers_.begin(), observers_.end(), [&](const std::weak_ptr<Callback>& wp) { return wp.lock() == cb_handle; }), observers_.end()); } // 通知所有观察者 void notify(const EventData& data) { cleanup_observers(); // 再次清理，确保通知时列表是干净的 for (const auto& wp : observers_) { if (auto sp = wp.lock()) { // 尝试锁定弱指针，如果对象还存在 (*sp)(data); // 调用回调 } } } // 模拟状态改变 void changeState(const std::string& msg, int val) { std::cout << "Subject state changed to: " << msg << ", " << val << std::endl; notify({msg, val}); } private: std::vector<std::weak_ptr<Callback>> observers_; // 内部清理已失效的弱指针 void cleanup_observers() { observers_.erase( std::remove_if(observers_.begin(), observers_.end(), [](const std::weak_ptr<Callback>& wp) { return wp.expired(); // 检查弱指针是否已过期（指向的对象已销毁） }), observers_.end()); } }; // 示例观察者类 class ConcreteObserver { public: ConcreteObserver(const std::string& name) : name_(name) {} void onEvent(const EventData& data) { std::cout << "[" << name_ << "] Received event: " << data.message << ", Value: " << data.value << std::endl; } private: std::string name_; }; /* int main() { Subject subject; // 观察者1：使用lambda表达式 auto obs1_handle = subject.attach([](const EventData& data) { std::cout << "[Lambda Observer] Event: " << data.message << std::endl; }); // 观察者2：使用成员函数 ConcreteObserver observer2("ObserverB"); // std::bind 可以将成员函数绑定到特定对象实例上 auto obs2_handle = subject.attach(std::bind(&ConcreteObserver::onEvent, &observer2, std::placeholders::_1)); // 观察者3：一个临时对象，生命周期结束后会自动从Subject中移除（因为weak_ptr） { ConcreteObserver observer3("ObserverC"); auto obs3_handle = subject.attach(std::bind(&ConcreteObserver::onEvent, &observer3, std::placeholders::_1)); subject.changeState("First update", 10); } // observer3 在这里销毁，其对应的 weak_ptr 会失效 std::cout << "n--- After ObserverC destroyed ---n"; subject.changeState("Second update", 20); // 手动移除观察者1 subject.detach(obs1_handle); std::cout << "n--- After Lambda Observer detached ---n"; subject.changeState("Third update", 30); return 0; } */
为什么传统的观察者模式在现代C++中显得笨拙？
说实话，当我回溯到C++98/03时代，那些观察者模式的实现，总让我觉得有点“重”。它通常需要你定义一个抽象的
Observer
基类，里面包含一个纯虚函数
update()
。然后，每个具体的观察者都得继承这个基类，并实现
update
方法。这种模式的笨拙之处，在我看来，主要体现在几个方面：
首先是类型耦合。
update
方法的签名是固定的，这意味着所有观察者都必须以相同的方式接收通知。如果你想传递不同类型的数据，你可能需要一个
void*
然后进行
static_cast
或
dynamic_cast
，这简直是类型安全的噩梦，或者你得定义一堆不同的
Observer
接口。这无疑增加了设计的复杂度和出错的概率。
其次是生命周期管理。传统的实现里，主题通常会持有观察者的裸指针。这就带来了一个经典的问题：如果一个观察者在主题不知情的情况下被销毁了，那么主题在尝试通知它时就会访问到一个悬空指针，结果就是程序崩溃。调试这种问题，那滋味可真不好受。你需要手动管理观察者的注册和注销，稍有不慎就可能引发问题。
再者，样板代码过多。每次实现一个新的观察者，你都得写一个类，继承，实现虚函数。对于一些简单的回调场景，比如我只想在某个按钮被点击时执行一个lambda表达式，这种模式就显得过于繁琐了。它强迫我们为每个回调都创建一个完整的类结构，这在追求简洁高效的现代编程实践中，无疑是一种负担。
现代C++的智能指针（如
std::shared_ptr
和
std::weak_ptr
）和
std::function
以及lambda表达式，恰好能优雅地解决这些痛点。
std::function
提供了极大的灵活性，让我们可以把任何可调用对象作为回调，不再受限于固定的虚函数签名。而
std::weak_ptr
则完美地解决了生命周期管理中的悬空指针问题，它允许主题“观察”观察者，而不会阻止观察者自身的销毁，这简直是天赐的解决方案。
如何利用C++11及更高版本特性简化观察者模式？
C++11及其后续标准，简直是为观察者模式的现代化改造量身定制的。我个人觉得，这些特性让我们的事件通知机制变得异常灵活，不再需要为每个事件类型都定义一个虚函数接口了，这多舒服啊。
最核心的两个利器，我认为是
std::function
和智能指针家族，特别是
std::weak_ptr
。
std::function
的魔力： 想象一下，你不再需要一个抽象的
Observer
基类，仅仅是为了一个
update
方法。现在，你可以用
std::function<void(const EventData&)>
来作为你的回调类型。这意味着你的观察者可以是：
- 一个普通的自由函数。
- 一个静态成员函数。
- 一个类的成员函数（通过
std::bind
或lambda捕获
）。
- 甚至是一个临时的lambda表达式。 这种类型擦除的能力，让你的
Subject
完全不用关心具体的回调是什么类型，只要它符合签名就行。这极大地解耦了主题和观察者，让设计变得更加开放和灵活。比如，我写一个ui库，按钮点击事件的回调可以直接是一个lambda，多方便啊，不用再为每个按钮事件都写一个继承自
ButtonObserver
的类了。
智能指针，特别是
std::weak_ptr
： 传统的观察者模式最大的痛点之一就是生命周期管理。主题持有观察者的裸指针，一旦观察者被销毁，主题就可能去访问一个无效地址。
std::weak_ptr
完美地解决了这个问题。当主题存储
std::weak_ptr<std::function<...>>
时，它不会增加观察者（或其回调对象）的引用计数。当主题需要通知时，它会尝试将
weak_ptr
提升为
std::shared_ptr
（通过
wp.lock()
）。如果提升成功，说明观察者仍然存活，可以安全地调用回调；如果提升失败（
lock()
返回
nullptr
），则说明观察者已经销毁了，主题可以安全地将其从列表中移除，避免了悬空指针的风险。这种机制，在我看来，简直是优雅至极，它把生命周期管理的复杂性大大降低了，让我们可以更专注于业务逻辑本身。
Lambda表达式的便捷： 结合
std::function
，lambda表达式让观察者的实现变得异常简洁。对于简单的事件响应，你甚至不需要定义一个完整的类，直接在注册时写一个lambda就行。这减少了大量的样板代码，让事件处理逻辑更加贴近使用点，提高了代码的可读性和维护性。
总而言之，现代C++的这些特性，让观察者模式从一个略显僵硬的设计模式，蜕变成了一个既强大又灵活、且非常安全的事件通知框架。
考虑多线程环境下的事件通知与常见陷阱
当我们将观察者模式引入多线程环境时，事情会变得稍微复杂一些，但并非无法处理。这里面确实有一些需要特别留心的地方，如果处理不好，轻则数据不一致，重则程序崩溃或死锁。
线程安全： 最直接的问题就是对观察者列表的并发访问。如果一个线程正在遍历列表并通知观察者，而另一个线程同时尝试添加或移除观察者，那么就可能发生数据竞争。这会导致迭代器失效，或者列表状态不正确。解决这个问题，通常我们会使用互斥锁（
std::mutex
）。在访问或修改观察者列表时，我们应该锁定互斥锁，确保同一时间只有一个线程能够操作列表。
// Subject类中添加一个互斥锁 class Subject { // ... private: std::vector<std::weak_ptr<Callback>> observers_; mutable std::mutex observers_mutex_; // 可变互斥锁，因为notify可能在const方法中调用 // ... public: std::shared_ptr<Callback> attach(Callback cb) { std::lock_guard<std::mutex> lock(observers_mutex_); // 锁定 // ... (原有的添加逻辑) cleanup_observers(); return shared_cb; } void detach(std::shared_ptr<Callback> cb_handle) { std::lock_guard<std::mutex> lock(observers_mutex_); // 锁定 // ... (原有的移除逻辑) } void notify(const EventData& data) { // 在通知前，复制一份观察者列表，然后释放锁，避免在回调中发生死锁 std::vector<std::shared_ptr<Callback>> current_observers; { std::lock_guard<std::mutex> lock(observers_mutex_); cleanup_observers(); // 在锁定状态下清理 for (const auto& wp : observers_) { if (auto sp = wp.lock()) { current_observers.push_back(sp); } } } // 锁在这里释放 // 现在可以安全地通知，即使回调中尝试修改observers_列表也不会死锁 for (const auto& sp : current_observers) { (*sp)(data); } } // ... };
注意，在
notify
方法中，我特意在获取观察者列表后就释放了锁。这是因为，如果我在持有锁的情况下调用观察者的回调，而某个回调函数又尝试去注册或注销观察者（这会再次尝试获取锁），那么就可能发生死锁。所以，一个常见的策略是：在锁的保护下复制一份当前的观察者列表，然后释放锁，再遍历这份复制的列表进行通知。
悬空观察者： 即使使用了
std::weak_ptr
来避免悬空指针，但如果观察者在收到通知并开始处理时被销毁了，仍可能出现问题。例如，观察者在回调中访问其成员变量，但此时对象已经被析构。这通常需要观察者自身具备更强的生命周期管理能力，或者回调中对
this
指针进行
weak_ptr
式的检查（如果回调是成员函数）。
通知顺序与并发性： 在多线程环境下，观察者被通知的顺序可能不再是严格的注册顺序。如果通知顺序很重要，你需要额外的机制来保证。此外，如果某些回调执行时间很长，它们可能会阻塞通知线程，影响系统的响应性。对于这种情况，可以考虑将通知本身也放入一个任务队列，由专门的线程池来处理，实现异步通知。
异常安全： 如果一个观察者的回调抛出了异常，而你没有捕获它，那么整个通知过程可能中断，甚至导致程序崩溃，其他观察者可能就收不到通知了。因此，在遍历通知时，最好在每个回调外部加上
块，确保一个观察者的异常不会影响到其他观察者。
// notify方法中的异常安全 void notify(const EventData& data) { // ... (复制列表和释放锁的部分) for (const auto& sp : current_observers) { try { (*sp)(data); } catch (const std::exception& e) { std::cerr << "Error notifying observer: " << e.what() << std::endl; // 可以在这里选择是否继续通知其他观察者 } catch (...) { std::cerr << "Unknown error notifying observer." << std::endl; } } }
处理多线程下的观察者模式，需要我们对并发编程有清晰的认识。它不仅仅是加个锁那么简单，更要考虑锁的粒度、死锁的可能性以及异常处理策略。但一旦设计得当，它能让你的系统在复杂的并发场景下依然保持健壮和响应。
