观察者模式通过解耦被观察者与观察者提升代码可维护性与扩展性。1. 它实现一对多的依赖关系，当被观察者状态变化时，所有观察者自动收到通知；2. 通过抽象接口（iobserver、isubjec++t）定义通信规范，使组件间仅依赖接口而非具体实现；3. 支持动态注册/注销观察者，便于灵活扩展新观察者而不修改原有逻辑；4. 提升事件驱动能力，适用于gui、日志系统等需异步响应的场景；5. 在c++中需注意内存管理（如使用智能指针）、并发访问控制及通知顺序等问题；6. 可进一步采用std::function、事件总线、信号槽机制或响应式编程等高级方案优化实现。
在C++中实现观察者模式，核心在于构建一种“一对多”的依赖关系：当一个对象（被观察者，Subject）的状态发生改变时，所有依赖于它的对象（观察者，Observer）都会得到通知并自动更新。这通常通过定义抽象接口、维护观察者列表以及一套注册/注销/通知机制来完成。
要实现观察者模式，我们通常会定义两个抽象基类：IObserver 和 ISubject。IObserver 负责接收通知，而 ISubject 则负责管理观察者并发送通知。
首先，我们定义观察者接口。它通常只包含一个 update 方法，用于接收被观察者的状态变化通知。
立即学习“C++免费学习笔记（深入）”；
#include <iostream>
#include <vector>
#include <string>
#include <algorithm> // For std::remove
// 前向声明，避免循环依赖
class ISubject;
// 抽象观察者接口
class IObserver {
public:
virtual ~IObserver() = default; // 确保派生类析构函数被调用
virtual void update(const std::string& message) = 0;
};
// 抽象被观察者接口
class ISubject {
public:
virtual ~ISubject() = default;
virtual void attach(IObserver* observer) = 0;
virtual void detach(IObserver* observer) = 0;
virtual void notify(const std::string& message) = 0;
};
// 具体被观察者
class ConcreteSubject : public ISubject {
private:
std::vector<IObserver*> observers_; // 存储观察者指针
std::string state_; // 被观察者的状态
public:
// 设置状态并通知所有观察者
void setState(const std::string& newState) {
state_ = newState;
std::cout << "Subject: State changed to '" << state_ << "'. Notifying observers...\n";
notify(state_); // 通知观察者状态已更新
}
// 实现attach方法：添加观察者
void attach(IObserver* observer) override {
// 简单检查是否已存在，避免重复添加
auto it = std::find(observers_.begin(), observers_.end(), observer);
if (it == observers_.end()) {
observers_.push_back(observer);
std::cout << "Subject: Observer attached.\n";
} else {
std::cout << "Subject: Observer already attached.\n";
}
}
// 实现detach方法：移除观察者
void detach(IObserver* observer) override {
// 使用erase-remove idiom 安全移除元素
auto it = std::remove(observers_.begin(), observers_.end(), observer);
if (it != observers_.end()) {
observers_.erase(it, observers_.end());
std::cout << "Subject: Observer detached.\n";
} else {
std::cout << "Subject: Observer not found for detachment.\n";
}
}
// 实现notify方法：遍历并通知所有观察者
void notify(const std::string& message) override {
for (IObserver* observer : observers_) {
if (observer) { // 确保指针有效
observer->update(message);
}
}
}
};
// 具体观察者
class ConcreteObserver : public IObserver {
private:
std::string name_;
// 也可以存储一个指向Subject的指针，以便在update时主动拉取数据 (pull model)
// 但在这个例子中，我们采用push model，直接传递消息
public:
ConcreteObserver(const std::string& name) : name_(name) {}
// 实现update方法：接收并处理通知
void update(const std::string& message) override {
std::cout << "Observer '" << name_ << "': Received update - '" << message << "'\n";
}
};
// 示例用法
int main() {
ConcreteSubject subject;
ConcreteObserver observer1("Observer A");
ConcreteObserver observer2("Observer B");
ConcreteObserver observer3("Observer C");
std::cout << "--- Initial Attachment ---\n";
subject.attach(&observer1);
subject.attach(&observer2);
subject.attach(&observer3);
std::cout << "\n--- First State Change ---\n";
subject.setState("Important Event 1");
std::cout << "\n--- Detaching Observer B ---\n";
subject.detach(&observer2);
std::cout << "\n--- Second State Change ---\n";
subject.setState("Critical Alert 2");
std::cout << "\n--- Re-attaching Observer B ---\n";
subject.attach(&observer2); // 重新附加
subject.setState("All Clear!");
// 注意：这里我们使用了原始指针，需要手动管理Observer的生命周期。
// 如果Observer的生命周期比Subject短，或者存在循环引用，
// 则需要考虑使用智能指针（如std::shared_ptr或std::weak_ptr）。
return 0;
}这段代码展示了观察者模式的经典结构。ConcreteSubject 维护一个 IObserver 指针的 std::vector，当其状态改变时，会遍历这个列表并调用每个观察者的 update 方法。ConcreteObserver 则实现了 update 方法来响应通知。这让被观察者和观察者之间实现了高度解耦，它们只需知道彼此的接口，而无需了解具体实现。
在我看来，观察者模式最核心的价值，就在于它为我们提供了一种优雅的方式来解耦系统中的不同组件。想象一下，如果你的系统里有一个模块（比如一个数据源）需要通知其他许多模块（比如UI界面、日志系统、分析模块）它的数据发生了变化，但它又不想直接依赖这些模块的具体实现。如果直接调用，那数据源模块就得知道所有这些模块的类型和方法，这会造成紧密的耦合。每次有新模块需要接收通知，你都得改动数据源模块的代码，这简直是灾难。
观察者模式恰好解决了这个问题。它引入了一个中间层：被观察者只知道它有一群“观察者”，它们都遵循 IObserver 接口。当状态改变时，它就通过这个接口统一地“广播”出去。至于具体哪个观察者收到了、它会怎么处理，被观察者一概不知，也不需要知道。这种“我只管发，你只管收”的模式，让发送者和接收者之间变得非常松散。
这种解耦带来的好处是显而易见的：
IObserver 接口并注册到被观察者即可，无需修改现有代码。这符合“开闭原则”（对扩展开放，对修改关闭）。说实话，我个人觉得，这种模式在构建复杂系统时简直是救星。它让我们可以把一个大问题拆解成多个小问题，每个小问题都能独立演进，而不会牵一发而动全身。这对于团队协作开发，或者系统需要频繁迭代的场景来说，简直是太友好了。
在C++中实现观察者模式，虽然核心思想简单，但由于C++的特性，特别是内存管理和多线程，我们不得不面对一些棘手的问题。我总结了一些常见的陷阱和需要深入考量的地方：
内存管理：谁来管理观察者的生命周期？
这是最常见也最头疼的问题。在上面的例子中，我们使用了原始指针 IObserver*。这意味着 ConcreteSubject 仅仅持有指向 IObserver 对象的指针，但并不拥有这些对象。如果一个 ConcreteObserver 对象在 ConcreteSubject 还在使用它之前就被析构了（比如它是一个栈上的局部变量，或者被 delete 了），那么 ConcreteSubject 里的指针就会变成“悬空指针”（dangling pointer）。一旦 ConcreteSubject 尝试通过这个悬空指针调用 update 方法，程序就会崩溃。
delete 掉所有观察者。但这通常不符合观察者模式的初衷，因为观察者往往有自己的生命周期。std::shared_ptr： 如果多个对象（包括被观察者）共享观察者的所有权，可以使用 std::shared_ptr<IObserver>。这样，只要有任何 shared_ptr 还在引用观察者，它就不会被销毁。std::weak_ptr： shared_ptr 有可能导致循环引用（如果观察者也持有被观察者的 shared_ptr），从而造成内存泄漏。此时，观察者可以持有被观察者的 std::weak_ptr，或者被观察者持有观察者的 std::weak_ptr。weak_ptr 不增加引用计数，在访问前需要先提升为 shared_ptr。这是更健壮的方案，但代码会稍微复杂一些。detach 方法将自己从被观察者中移除。这需要开发者严格遵守约定。通知顺序与并发问题：
ConcreteSubject 遍历 observers_ 列表的顺序就是通知的顺序。在大多数情况下，这个顺序可能不重要。但如果某些观察者的行为依赖于其他观察者完成更新，那么通知顺序就变得关键。如果需要特定顺序，可能需要对 observers_ 列表进行排序，或者提供优先级机制。attach、detach 和 notify 方法可能在不同的线程中被调用，那么 observers_ 列表的访问就会存在并发问题。例如，一个线程正在遍历列表进行 notify，另一个线程同时调用 detach 移除一个观察者，这可能导致迭代器失效或数据竞争。std::mutex）来保护 observers_ 列表的访问。在 attach、detach 和 notify 方法中，对列表的读写操作都应该加锁。notify，一种常见做法是先将 observers_ 列表复制一份，然后遍历副本进行通知。这样在通知过程中，即使原始列表被修改，也不会影响当前正在进行的通知。但要注意，复制列表会带来额外的开销。“拉取”与“推送”模型选择：
update 方法中直接把数据（message）传递给观察者，就像我们上面例子做的。这简单直接，但可能传递了观察者不需要的数据，或者数据量过大。getState()）去获取。这让观察者有更多控制权，只获取自己需要的数据，但可能需要观察者持有被观察者的指针。通知的粒度与“过度通知”： 如果被观察者状态变化频繁，且每次变化都触发通知，可能会导致“通知风暴”，影响性能。
update 方法中传递事件类型或更详细的上下文信息，让观察者可以过滤掉不关心的通知。这些都是在实际项目中，我反复踩坑后总结出来的经验。Observer模式本身不复杂，但把它用好、用对，特别是在C++这种需要手动管理资源的语言里，确实需要多一份细心和考量。
当然有！观察者模式虽然经典，但它也不是万能药。在更复杂的场景下，或者为了追求更高的便利性和安全性，社区也发展出了一些高级变体或替代方案。在我看来，这些方案往往是在解决原生观察者模式的一些痛点，或者将其理念推广到更广阔的领域。
基于 std::function 和 Lambda 的轻量级观察者：
C++11引入的 std::function 和 Lambda 表达式，让我们可以用更简洁的方式实现回调机制，很多时候甚至可以替代传统的 IObserver 接口。
IObserver* 列表，而是维护一个 std::vector<std::function<void(const std::string&)>>。观察者注册时，直接传入一个 Lambda 表达式或一个可调用对象。IObserver 类，特别是对于那些只需要简单响应的观察者。IObserver 那样方便地 detach 特定观察者（因为Lambda是匿名的，难以识别）。通常需要返回一个句柄或ID来管理注销。事件总线（Event Bus）/中介者模式（Mediator Pattern）： 当系统中有许多被观察者和许多观察者，并且它们之间的关系变得错综复杂时，直接的观察者模式可能会导致“意大利面条式”的连接。事件总线或中介者模式应运而生。
Boost.Signals2 或 Qt Signals & Slots： 这些是C++社区中非常成熟且广泛使用的事件/信号槽库。它们是对观察者模式的高度抽象和封装，提供了类型安全、线程安全和自动连接/断开等高级特性。
std::function 和 std::shared_ptr 实现，非常C++范式。响应式编程（Reactive Programming，如 RxCpp）： 这是一种更高级的事件处理范式，将事件流视为“数据流”，并提供丰富的操作符来转换、组合和过滤这些流。Rx（Reactive Extensions）系列库（如RxCpp）将观察者模式的概念推向了极致。
在我看来，选择哪种方案，很大程度上取决于项目的规模、复杂性、性能要求以及团队对新技术的接受程度。对于简单的内部事件，Lambda可能就够了；对于中大型项目，Boost.Signals2或Qt Signals & Slots是很好的选择；而对于需要处理复杂异步数据流的场景，响应式编程则能带来革命性的效率提升。每种方案都有其闪光点，也都有其局限性，关键在于理解其背后的设计哲学，并根据实际需求做出明智的抉择。
以上就是怎样用C++实现观察者模式 事件处理与解耦设计实例解析的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
734
收藏
