C++观察者模式如何设计 使用现代C++实现事件通知机制

传统的观察者模式在现代c++++中显得笨拙，主要体现在类型耦合、生命周期管理困难和样板代码过多。1. 类型耦合：update方法签名固定，难以传递不同类型的数据，需大量接口或强制类型转换；2. 生命周期管理：主题持有裸指针，易导致悬空指针和程序崩溃；3. 样板代码：每个观察者都必须继承基类并实现虚函数，增加冗余代码。现代c++通过std::function、lambda表达式和智能指针解决了这些问题，提升了灵活性与安全性。

C++中设计观察者模式，核心在于构建一种“一对多”的依赖关系，当一个对象的状态发生变化时，所有依赖于它的对象都会收到通知并自动更新。在现代C++的语境下，我们不再需要拘泥于传统的纯虚函数接口和裸指针，而是可以巧妙地利用C++11及更高版本提供的特性，如

std::function

解决方案

设计现代C++观察者模式，我们通常会定义一个“主题”（Subject）类和一个“观察者”（Observer）概念。主题负责维护一个观察者列表，并在自身状态改变时通知它们。观察者则注册到主题上，并提供一个回调方法来接收通知。

核心设计思路：

立即学习“C++免费学习笔记（深入）”；

1. 主题（Subject）类：

   
   • 维护一个观察者列表。这个列表最好使用

     std::vector>

     ，其中

     CallbackType

     可以是

     std::function

     ，这样既能处理观察者的生命周期问题，又能保持回调的通用性。
   • 提供

     attach

     （注册观察者）和

     detach

     （移除观察者）方法。
   • 提供

     notify

     方法，遍历列表并调用每个观察者的回调。

2. 观察者（Observer）概念：

   • 不再强制定义一个纯虚基类，而是通过提供一个可调用的对象（如lambda、函数指针或

     std::function

     包装的成员函数）来作为回调。
   • 如果观察者是一个对象，它通常会持有主题的

     std::shared_ptr

     （或者一个

     std::weak_ptr

     以避免循环引用，如果主题也持有观察者的

     shared_ptr

     ）。

代码示例骨架：

#include 
#include 
#include 
#include  // For std::shared_ptr, std::weak_ptr
#include  // For std::remove_if

// 定义一个通用的事件数据结构，或者直接传递可变参数
struct EventData {
    std::string message;
    int value;
};

// Subject类
class Subject {
public:
    // 回调类型，这里以EventData为例，也可以是void()或其它签名
    using Callback = std::function;

    // 注册观察者：返回一个shared_ptr，方便外部管理其生命周期，
    // 内部存储weak_ptr，避免循环引用和悬空指针
    std::shared_ptr attach(Callback cb) {
        auto shared_cb = std::make_shared(std::move(cb));
        observers_.push_back(std::weak_ptr(shared_cb));
        // 清理无效的弱指针（已销毁的观察者）
        cleanup_observers();
        return shared_cb;
    }

    // 移除观察者：通过比较shared_ptr的地址来移除
    void detach(std::shared_ptr cb_handle) {
        observers_.erase(
            std::remove_if(observers_.begin(), observers_.end(),
                [&](const std::weak_ptr& 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> observers_;

    // 内部清理已失效的弱指针
    void cleanup_observers() {
        observers_.erase(
            std::remove_if(observers_.begin(), observers_.end(),
                [](const std::weak_ptr& 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

std::function

std::weak_ptr

如何利用C++11及更高版本特性简化观察者模式？

C++11及其后续标准，简直是为观察者模式的现代化改造量身定制的。我个人觉得，这些特性让我们的事件通知机制变得异常灵活，不再需要为每个事件类型都定义一个虚函数接口了，这多舒服啊。

一览AI绘图

一览AI绘图是一览科技推出的AIGC作图工具，用AI灵感助力，轻松创作高品质图片

下载

最核心的两个利器，我认为是

std::function

std::weak_ptr

std::function

Observer

update

std::function

• 一个普通的自由函数。
• 一个静态成员函数。
• 一个类的成员函数（通过

  std::bind

  或lambda捕获

  this

  ）。
• 甚至是一个临时的lambda表达式。 这种类型擦除的能力，让你的

  Subject

  完全不用关心具体的回调是什么类型，只要它符合签名就行。这极大地解耦了主题和观察者，让设计变得更加开放和灵活。比如，我写一个UI库，按钮点击事件的回调可以直接是一个lambda，多方便啊，不用再为每个按钮事件都写一个继承自

  ButtonObserver

  的类了。

智能指针，特别是

std::weak_ptr

std::weak_ptr

std::weak_ptr>

weak_ptr

std::shared_ptr

wp.lock()

lock()

nullptr

Lambda表达式的便捷： 结合

std::function

总而言之，现代C++的这些特性，让观察者模式从一个略显僵硬的设计模式，蜕变成了一个既强大又灵活、且非常安全的事件通知框架。

考虑多线程环境下的事件通知与常见陷阱

当我们将观察者模式引入多线程环境时，事情会变得稍微复杂一些，但并非无法处理。这里面确实有一些需要特别留心的地方，如果处理不好，轻则数据不一致，重则程序崩溃或死锁。

线程安全： 最直接的问题就是对观察者列表的并发访问。如果一个线程正在遍历列表并通知观察者，而另一个线程同时尝试添加或移除观察者，那么就可能发生数据竞争。这会导致迭代器失效，或者列表状态不正确。解决这个问题，通常我们会使用互斥锁（

std::mutex

// Subject类中添加一个互斥锁
class Subject {
    // ...
private:
    std::vector> observers_;
    mutable std::mutex observers_mutex_; // 可变互斥锁，因为notify可能在const方法中调用
    // ...

public:
    std::shared_ptr attach(Callback cb) {
        std::lock_guard lock(observers_mutex_); // 锁定
        // ... (原有的添加逻辑)
        cleanup_observers();
        return shared_cb;
    }

    void detach(std::shared_ptr cb_handle) {
        std::lock_guard lock(observers_mutex_); // 锁定
        // ... (原有的移除逻辑)
    }

    void notify(const EventData& data) {
        // 在通知前，复制一份观察者列表，然后释放锁，避免在回调中发生死锁
        std::vector> current_observers;
        {
            std::lock_guard 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

通知顺序与并发性： 在多线程环境下，观察者被通知的顺序可能不再是严格的注册顺序。如果通知顺序很重要，你需要额外的机制来保证。此外，如果某些回调执行时间很长，它们可能会阻塞通知线程，影响系统的响应性。对于这种情况，可以考虑将通知本身也放入一个任务队列，由专门的线程池来处理，实现异步通知。

异常安全： 如果一个观察者的回调抛出了异常，而你没有捕获它，那么整个通知过程可能中断，甚至导致程序崩溃，其他观察者可能就收不到通知了。因此，在遍历通知时，最好在每个回调外部加上

try-catch

// 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;
        }
    }
}

处理多线程下的观察者模式，需要我们对并发编程有清晰的认识。它不仅仅是加个锁那么简单，更要考虑锁的粒度、死锁的可能性以及异常处理策略。但一旦设计得当，它能让你的系统在复杂的并发场景下依然保持健壮和响应。