观察者模式在C++中通过抽象基类Observer和Subject实现一对多依赖，支持对象间解耦。具体主题状态变更时，调用notify通知所有注册的观察者，后者通过update方法响应变化。该模式利用多态性实现运行时绑定，适用于事件驱动系统和GUI编程，体现开闭原则。常见陷阱包括内存管理问题、迭代器失效和循环引用，最佳实践推荐使用std::weak_ptr管理生命周期、避免dynamic_cast、保证线程安全，并采用推送或拉取优化通知机制。相比传统实现，Qt或Boost.Signals2等信号/槽机制提供类型安全、参数灵活、自动生命周期管理等优势，是观察者模式的高级演进形式，适用于复杂场景；而手动实现则更轻量，适合简单需求。两者核心思想一致，均致力于解耦发布者与订阅者。
在C++中实现观察者模式，核心在于构建一种“一对多”的依赖关系，让多个观察者对象能够监听并自动接收一个主题对象的状态变更通知，而无需知道彼此的具体类型。这本质上是一种解耦机制，它将数据（主题）与呈现或处理数据的方式（观察者）分离，极大地提升了系统的灵活性和可维护性。
解决方案
要实现观察者模式，我们通常会定义两个抽象基类：Observer（观察者）和 Subject（主题）。
1. 定义观察者接口 (Observer Interface)
立即学习“C++免费学习笔记（深入）”；
这是一个纯虚基类，声明一个 update 方法，所有具体观察者都必须实现它。当主题状态改变时，会调用此方法通知观察者。
#include <iostream>
#include <vector>
#include <algorithm> // For std::remove
// 前向声明 Subject，避免循环引用
class Subject;
class Observer {
public:
virtual ~Observer() = default;
// update 方法可以根据需要传递主题的引用，或者主题状态的特定数据
virtual void update(Subject& changedSubject) = 0;
};2. 定义主题接口 (Subject Interface)
同样是一个纯虚基类，它包含用于管理观察者的方法：attach（注册观察者）、detach（移除观察者）和 notify（通知所有观察者）。
class Subject {
public:
virtual ~Subject() = default;
void attach(Observer* observer) {
// 避免重复添加
if (std::find(observers_.begin(), observers_.end(), observer) == observers_.end()) {
observers_.push_back(observer);
}
}
void detach(Observer* observer) {
observers_.erase(std::remove(observers_.begin(), observers_.end(), observer), observers_.end());
}
void notify() {
// 遍历并通知所有注册的观察者
for (Observer* observer : observers_) {
observer->update(*this); // 传递自身引用
}
}
private:
std::vector<Observer*> observers_;
};3. 实现具体主题 (Concrete Subject)
继承自 Subject，并维护自己的状态。当状态发生变化时，它会调用 notify() 方法来通知所有注册的观察者。
class ConcreteSubject : public Subject {
public:
int getState() const {
return state_;
}
void setState(int newState) {
if (state_ != newState) {
state_ = newState;
std::cout << "Subject state changed to: " << state_ << std::endl;
notify(); // 状态改变时通知观察者
}
}
private:
int state_ = 0;
};4. 实现具体观察者 (Concrete Observer)
继承自 Observer，并实现 update 方法来响应主题的通知。它通常会从主题那里获取最新的状态并进行相应的处理。
class ConcreteObserverA : public Observer {
public:
ConcreteObserverA(const std::string& name) : name_(name) {}
void update(Subject& changedSubject) override {
// 尝试将 Subject 转换为 ConcreteSubject 来获取具体状态
ConcreteSubject* concreteSubject = dynamic_cast<ConcreteSubject*>(&changedSubject);
if (concreteSubject) {
std::cout << name_ << " received update. New state: " << concreteSubject->getState() << std::endl;
// 这里可以根据状态进行更复杂的逻辑处理
} else {
std::cout << name_ << " received update from an unknown subject type." << std::endl;
}
}
private:
std::string name_;
};
class ConcreteObserverB : public Observer {
public:
ConcreteObserverB(const std::string& name) : name_(name) {}
void update(Subject& changedSubject) override {
ConcreteSubject* concreteSubject = dynamic_cast<ConcreteSubject*>(&changedSubject);
if (concreteSubject) {
std::cout << name_ << " observed state change. Current state: " << concreteSubject->getState() << ". Performing specific action." << std::endl;
}
}
private:
std::string name_;
};5. 客户端代码示例
int main() {
ConcreteSubject subject;
ConcreteObserverA observer1("Observer A");
ConcreteObserverB observer2("Observer B");
ConcreteObserverA observer3("Observer C");
subject.attach(&observer1);
subject.attach(&observer2);
subject.attach(&observer3);
std::cout << "\n--- Setting subject state to 10 ---\n";
subject.setState(10); // 所有观察者都会被通知
std::cout << "\n--- Detaching Observer B ---\n";
subject.detach(&observer2);
std::cout << "\n--- Setting subject state to 20 ---\n";
subject.setState(20); // 只有 Observer A 和 C 会被通知
// 观察者模式的生命周期管理通常需要仔细考虑，这里为了示例简单，直接在栈上创建对象。
// 实际项目中，观察者和主题的生命周期往往更复杂，可能需要智能指针。
return 0;
}为什么观察者模式在C++中如此重要？
在我看来，观察者模式在C++里之所以重要，主要在于它提供了一种优雅的方式来处理对象间的解耦问题。我们经常会遇到这样的场景：一个对象的改变需要通知其他多个对象，但我们又不希望这些对象之间产生紧密的耦合。比如，一个用户界面上的按钮被点击，可能需要更新多个数据模型、刷新不同的视图组件，甚至触发网络请求。如果这些逻辑直接在按钮的事件处理函数里硬编码，那代码会变得一团糟，而且任何一个部分的修改都可能牵连到其他部分。
观察者模式通过引入抽象层，使得主题（发布者）和观察者（订阅者）可以独立变化。主题只知道它有一群“观察者”，它们都实现了某个 update() 接口，但它不知道这些观察者具体是谁、做什么。这极大地提升了系统的灵活性和可扩展性。想象一下，如果我要增加一个新的日志记录器，来记录每次状态变更，我只需要创建一个新的 ConcreteObserver，然后把它注册到 Subject 上，完全不需要修改 Subject 本身的代码。这不就是我们常说的“开闭原则”的体现吗？
更深一层看，C++的多态性是实现观察者模式的基石。通过虚函数和基类指针，我们可以实现运行时绑定，让 Subject 在 notify() 时，能够调用不同 ConcreteObserver 对象的 update() 方法。这对于构建事件驱动系统、GUI编程（虽然现代GUI框架通常有更高级的信号/槽机制，但其底层思想与观察者模式一脉相承）、以及任何需要“当X发生时，做Y和Z”的场景都非常适用。它让代码结构更清晰，更易于理解和维护，也为单元测试提供了便利，因为我们可以单独测试主题或观察者，而不需要依赖整个复杂的系统。
C++实现观察者模式时常见的陷阱与最佳实践？
在我实际使用观察者模式的过程中，确实遇到过一些“坑”，也总结出了一些心得。这模式看着简单，但要用好，尤其是在C++这种需要手动管理资源的环境下，还真得注意几点。
常见的陷阱：
detach），那么主题在尝试 notify() 时就会访问到一个无效的内存地址，导致程序崩溃。反过来，如果主题被销毁了，而观察者还在尝试访问它，同样会出问题。std::vector 存储观察者时，其迭代顺序通常是注册顺序，但这并非总是能保证，而且如果某个观察者在 update() 过程中又注册或反注册了其他观察者，就可能导致迭代器失效或逻辑混乱。std::shared_ptr）互相持有对方，就可能形成循环引用，导致内存泄漏。update() 方法，可能会产生显著的性能开销。update(Subject& changedSubject) 中，观察者需要 dynamic_cast 回 ConcreteSubject 来获取具体状态。这其实引入了一点点耦合，而且如果主题状态复杂，观察者可能只关心其中一部分，但主题却“推送”了所有信息，或者观察者需要“拉取”很多不必要的信息。最佳实践：
std::weak_ptr<Observer>：这是处理内存管理问题的“银弹”。主题不再直接持有原始 Observer* 指针，而是持有 std::weak_ptr<Observer>。在 notify() 时，先尝试 lock() 弱指针获取 std::shared_ptr。如果 lock() 失败（即观察者已被销毁），就从列表中移除该弱指针。这样，观察者的生命周期可以独立于主题，当观察者不再存在时，主题也不会崩溃。std::shared_ptr<Subject>：如果观察者需要保证在处理通知期间主题不被销毁，可以持有主题的 std::shared_ptr。update 方法可以接收更具体的事件对象或状态数据，而不是仅仅一个 Subject 引用。例如 update(const EventData& event)。这样观察者无需 dynamic_cast，也无需再向主题查询状态，减少了耦合。update 方法中传递一个枚举或标识符，指示观察者应该拉取哪个属性，避免不必要的查询。attach、detach 和 notify 方法都需要加锁（如 std::mutex）来保证线程安全，防止数据竞争。std::map 或其他有序容器来存储观察者，或者为观察者引入优先级机制。但通常来说，如果设计得当，观察者之间应该是相互独立的，不应有严格的通知顺序依赖。update() 过程中需要 detach 自身或其他观察者，直接修改 observers_ 列表可能会导致迭代器失效。一种常见的做法是，将待添加/删除的观察者放入一个临时队列，在 notify() 循环结束后再统一处理。dynamic_cast：尽量通过 update 方法的参数传递足够的信息，避免在观察者内部频繁使用 dynamic_cast 来获取具体主题类型。这会增加耦合，也可能导致运行时错误。如果确实需要区分不同类型的主题，可以考虑使用模板方法、访问者模式或更细粒度的观察者接口。观察者模式与C++标准库中的信号/槽机制有何异同？
谈到C++中的观察者模式，很难不联想到一些框架中提供的“信号/槽”（Signals and Slots）机制，比如Qt或者Boost.Signals2。虽然C++标准库本身并没有直接提供一套完整的信号/槽机制，但其核心思想与观察者模式高度契合，可以看作是观察者模式的一种高级、类型安全且通常更为灵活的实现。
相同之处：
不同之处：
Observer 接口，其 update() 方法签名是固定的（例如 void update(Subject&)）。这意味着所有观察者接收通知的方式和参数类型都是统一的。如果需要传递不同的数据，可能需要 dynamic_cast 或在 Subject 中存储更多状态，这增加了耦合和复杂性。dynamic_cast 和额外的状态查询。例如，一个 buttonClicked(int x, int y) 信号可以直接连接到一个 handleMouseClick(int posX, int posY) 槽。std::function)、成员函数指针、甚至代码生成（如Qt的moc），来提供类型安全的连接和断开机制。这使得使用起来更方便、更安全，但其内部实现远比手动实现观察者模式复杂。Observer 接口并实现 update() 方法来“订阅”主题。订阅和取消订阅通过 attach() 和 detach() 方法，传入观察者对象指针。connect() 函数将一个对象的信号与另一个对象的槽（可以是成员函数、静态函数、lambda表达式或函数对象）连接起来。这种连接更加灵活，不要求槽函数所在的类必须继承某个特定接口。std::weak_ptr 等智能指针。总结来说，信号/槽机制可以被看作是观察者模式在C++中一个更高级、更通用、更易用且类型安全的演进。如果你在构建一个大型、事件驱动的系统，并且可以依赖一个提供信号/槽的框架（如Qt），那么它通常是比传统观察者模式更好的选择。但如果项目限制，或者只需要一个轻量级的通知机制，手动实现观察者模式依然是一个非常有效且直接的方案。两者并非互斥，而是各有侧重，共同服务于解耦和事件通知的核心思想。
以上就是c++++如何实现观察者模式_c++设计模式之观察者模式实践的详细内容，更多请关注php中文网其它相关文章！
c++怎么学习？c++怎么入门？c++在哪学？c++怎么学才快？不用担心，这里为大家提供了c++速学教程(入门到精通)，有需要的小伙伴保存下载就能学习啦！
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
232
收藏
