1. 项目概述为什么我们需要观察者模式在C项目里尤其是那些涉及复杂UI交互、游戏事件系统或者需要解耦业务逻辑的场景你是不是经常遇到这样的麻烦一个对象的状态改变了得手动去通知一堆其他对象更新代码里到处都是if (condition) { updateA(); updateB(); ... }牵一发而动全身维护起来头大如斗。这就是典型的“紧耦合”问题各个模块像一团乱麻缠在一起。观察者模式就是为了解决这个痛点而生的。它是一种行为设计模式核心思想是定义了一种一对多的依赖关系。当一个对象我们称之为“主题”或“被观察者”的状态发生改变时所有依赖于它的对象我们称之为“观察者”都会自动得到通知并被更新。你可以把它想象成微信公众号的订阅机制你观察者关注了某个公众号主题。公众号一发布新文章状态改变所有订阅者观察者列表的手机就会自动收到推送通知更新回调而公众号完全不需要知道具体是谁订阅了它。对于C开发者尤其是面临面试或构建中大型项目的朋友深入理解并手写实现观察者模式绝不仅仅是背下一个设计模式的名字。它能让你从根本上理解如何设计松耦合、高内聚的系统架构写出更灵活、更易扩展的代码。无论是游戏里的成就系统、UI控件的数据绑定还是分布式系统中的事件总线其底层思想都离不开观察者模式。接下来我们就从思想到代码彻底拆解这个模式让你不仅能写出标准实现更能理解其变种和实战中的精妙之处。2. 模式思想深度拆解不仅仅是“订阅-发布”2.1 核心角色与职责要理解观察者模式首先得搞清楚戏台上的几个关键角色Subject主题/被观察者职责维护一个观察者对象的列表。提供“添加”、“删除”和“通知”观察者的接口。关键点它只知道有一群观察者在盯着它但完全不知道这些观察者具体是谁、是干什么的。它只负责在自身状态变化时遍历列表调用每个观察者的某个约定好的方法比如update。Observer观察者职责定义一个更新接口通常是纯虚函数用于接收来自主题的通知。关键点所有具体的观察者都必须实现这个接口。当主题通知时观察者通过这个接口获取更新并执行自己的业务逻辑。观察者可以订阅多个不同的主题。ConcreteSubject具体主题职责继承或实现Subject。它拥有实际的状态当这些状态改变时调用继承的“通知”方法。关键点它是触发通知的源头。通常我们会在它的状态设置函数setState里加入通知逻辑。ConcreteObserver具体观察者职责实现Observer接口。保存一个指向ConcreteSubject的引用或指针以便在收到通知时能获取主题的具体状态。关键点它实现了具体的响应行为。比如一个UI标签观察者在收到通知后会去读取主题的最新数据并更新显示。注意这里有一个经典的设计抉择——是采用“推”模型还是“拉”模型在“推”模型中主题在通知时会将被改变的数据作为参数传递给观察者。在“拉”模型中主题只发送一个简单的通知观察者收到通知后主动去主题那里“拉取”所需的数据。C实现中两者都很常见推模型更直接拉模型则更灵活观察者按需索取我们后续的代码会展示拉模型因为它更符合松耦合的精神。2.2 模式的价值与适用场景理解了角色我们再来看看这个模式到底好在哪里以及什么时候该用它价值一解耦这是最大的好处。主题和观察者之间依赖于抽象Subject和Observer接口而非具体实现。你可以独立地复用或修改主题或观察者只要接口不变另一边就无需改动。价值二支持广播通信主题不需要指定接收者通知会自动发给所有观察者。这在事件处理系统中非常有用。价值三符合开闭原则你可以随时增加新的观察者类而无需修改主题的代码。系统扩展变得非常容易。那么什么场景下你应该考虑使用观察者模式呢GUI事件处理按钮点击、鼠标移动等事件监听这些事件的控件就是观察者。数据模型与视图分离MVC/MVVM架构中当模型主题数据变化时多个视图观察者需要自动更新。游戏开发成就系统观察者监听玩家击杀、收集等事件、AI系统AI监听玩家位置变化。分布式系统的消息中间件生产者主题发布消息多个消费者观察者订阅并处理。监控与日志系统被监控的服务主题状态变化触发多个日志记录器、报警器观察者工作。3. 基础代码实现从零搭建一个松耦合系统理论说再多不如一行代码。我们来实现一个经典的例子一个气象站WeatherStation作为具体主题负责收集温度、湿度数据。多个显示设备如CurrentConditionsDisplay当前状况显示板、StatisticsDisplay统计显示板作为具体观察者订阅气象站的数据更新。当气象站数据变化时所有显示板自动更新。3.1 定义观察者与主题接口这是模式的基石定义了通信的契约。// Observer.h - 观察者接口 #ifndef OBSERVER_H #define OBSERVER_H // 前向声明避免头文件循环依赖。Observer只需要知道Subject存在不需要知道其细节。 class Subject; class Observer { public: virtual ~Observer() default; // 基类虚析构函数确保派生类对象能被正确释放 // 更新接口。当主题状态改变时主题会调用此方法。 // 参数subject指向状态发生改变的主题对象观察者可以据此查询主题状态。 virtual void update(Subject* subject) 0; }; #endif // OBSERVER_H// Subject.h - 主题接口 #ifndef SUBJECT_H #define SUBJECT_H #include vector #include memory // 用于std::shared_ptr #include “Observer.h” // 需要知道Observer类 class Subject { public: virtual ~Subject() default; // 注册观察者 virtual void registerObserver(std::shared_ptrObserver observer) 0; // 移除观察者 virtual void removeObserver(std::shared_ptrObserver observer) 0; // 通知所有观察者 virtual void notifyObservers() 0; }; #endif // SUBJECT_H实操心得这里使用了std::shared_ptrObserver来管理观察者的生命周期。这是一个现代C的推荐做法可以避免手动内存管理的麻烦和悬空指针的风险。主题持有观察者的智能指针当最后一个持有该观察者的主题被销毁时观察者对象也会被自动清理。当然如果观察者的生命周期由其他模块严格管理使用原始指针或std::weak_ptr也是可行的但shared_ptr在大多数情况下是最省心的选择。3.2 实现具体主题气象站具体主题需要维护状态和观察者列表并在状态改变时触发通知。// WeatherStation.h #ifndef WEATHER_STATION_H #define WEATHER_STATION_H #include “Subject.h” #include memory #include vector #include algorithm // 用于std::remove class WeatherStation : public Subject { private: std::vectorstd::shared_ptrObserver observers_; // 观察者列表 float temperature_; float humidity_; float pressure_; public: WeatherStation() : temperature_(0.0f), humidity_(0.0f), pressure_(1013.25f) {} // 实现Subject接口 void registerObserver(std::shared_ptrObserver observer) override { observers_.push_back(observer); } void removeObserver(std::shared_ptrObserver observer) override { // 使用erase-remove惯用法来移除元素 observers_.erase( std::remove(observers_.begin(), observers_.end(), observer), observers_.end() ); } void notifyObservers() override { for (auto observer : observers_) { if (auto obs observer.lock()) { // 使用weak_ptr时需检查shared_ptr则直接调用 obs-update(this); // “拉”模型将自身指针传给观察者 } } } // 设置气象数据并在设置后自动通知观察者 void setMeasurements(float temperature, float humidity, float pressure) { temperature_ temperature; humidity_ humidity; pressure_ pressure; measurementsChanged(); // 数据改变触发更新流程 } // 供观察者“拉取”数据的接口 float getTemperature() const { return temperature_; } float getHumidity() const { return humidity_; } float getPressure() const { return pressure_; } private: // 封装通知逻辑确保数据设置后必然通知 void measurementsChanged() { notifyObservers(); } }; #endif // WEATHER_STATION_H3.3 实现具体观察者显示板观察者需要在构造函数中订阅主题并在update方法中做出响应。// CurrentConditionsDisplay.h #ifndef CURRENT_CONDITIONS_DISPLAY_H #define CURRENT_CONDITIONS_DISPLAY_H #include “Observer.h” #include “WeatherStation.h” // 需要知道具体主题以获取数据 #include iostream class CurrentConditionsDisplay : public Observer { private: // 持有对主题的引用这里用指针用于“拉取”数据 WeatherStation* weatherStation_; float temperature_; float humidity_; public: // 构造函数中注册自己到主题 explicit CurrentConditionsDisplay(WeatherStation* station) : weatherStation_(station), temperature_(0.0f), humidity_(0.0f) { if (weatherStation_) { // 注意这里需要将this指针转换为shared_ptr。 // 在实际项目中观察者对象本身通常也由智能指针管理。 // 这里为了示例简单假设Display对象生命周期由外部管理。 // 更安全的做法是让Display也继承std::enable_shared_from_this。 weatherStation_-registerObserver(std::shared_ptrObserver(this)); } } ~CurrentConditionsDisplay() override { if (weatherStation_) { // 析构时取消注册防止主题通知一个已销毁的对象 weatherStation_-removeObserver(std::shared_ptrObserver(this)); } } void update(Subject* subject) override { // 安全转换确保通知来自我们关心的主题 if (auto ws dynamic_castWeatherStation*(subject)) { temperature_ ws-getTemperature(); humidity_ ws-getHumidity(); display(); } } void display() const { std::cout “[当前状况显示] 温度: “ temperature_ “°C, 湿度: “ humidity_ “%” std::endl; } }; #endif // CURRENT_CONDITIONS_DISPLAY_H// StatisticsDisplay.h - 另一个观察者示例 #ifndef STATISTICS_DISPLAY_H #define STATISTICS_DISPLAY_H #include “Observer.h” #include “WeatherStation.h” #include iostream #include vector #include numeric // for std::accumulate class StatisticsDisplay : public Observer { private: WeatherStation* weatherStation_; std::vectorfloat tempHistory_; float maxTemp_ -100.0f; float minTemp_ 100.0f; float avgTemp_ 0.0f; public: explicit StatisticsDisplay(WeatherStation* station) : weatherStation_(station) { if (weatherStation_) { weatherStation_-registerObserver(std::shared_ptrObserver(this)); } } ~StatisticsDisplay() override { if (weatherStation_) { weatherStation_-removeObserver(std::shared_ptrObserver(this)); } } void update(Subject* subject) override { if (auto ws dynamic_castWeatherStation*(subject)) { float currentTemp ws-getTemperature(); tempHistory_.push_back(currentTemp); // 更新统计值 maxTemp_ std::max(maxTemp_, currentTemp); minTemp_ std::min(minTemp_, currentTemp); avgTemp_ std::accumulate(tempHistory_.begin(), tempHistory_.end(), 0.0f) / tempHistory_.size(); display(); } } void display() const { std::cout “[统计显示] 平均/最高/最低温度: “ avgTemp_ “°C / “ maxTemp_ “°C / “ minTemp_ “°C” std::endl; } }; #endif // STATISTICS_DISPLAY_H3.4 组装与运行体验松耦合的魅力最后我们写一个简单的main函数来验证整个系统的工作。// main.cpp #include “WeatherStation.h” #include “CurrentConditionsDisplay.h” #include “StatisticsDisplay.h” #include memory int main() { // 1. 创建主题气象站 WeatherStation weatherStation; // 2. 创建观察者显示板并传入主题进行注册 CurrentConditionsDisplay currentDisplay(weatherStation); StatisticsDisplay statsDisplay(weatherStation); std::cout “ 第一次数据更新 ” std::endl; // 3. 主题数据更新自动通知所有观察者 weatherStation.setMeasurements(25.0f, 65.0f, 1012.0f); std::cout “\n 第二次数据更新 ” std::endl; weatherStation.setMeasurements(26.5f, 70.0f, 1011.5f); std::cout “\n 第三次数据更新 ” std::endl; weatherStation.setMeasurements(24.0f, 90.0f, 1013.0f); // 4. 观察者会在每次setMeasurements后自动显示新数据 return 0; }运行这个程序你会看到每次调用weatherStation.setMeasurements后两个显示板都会自动打印出最新的信息而气象站完全不知道显示板是如何工作的。这就是观察者模式实现的松耦合通信。4. 进阶实现与关键问题剖析上面的基础实现已经揭示了模式的核心但在实际项目中直接这样用可能会踩坑。我们来深入几个关键问题并给出更健壮的解决方案。4.1 内存管理与生命周期陷阱这是C实现观察者模式最容易出问题的地方。在上面的示例中我们在CurrentConditionsDisplay的构造函数里用std::shared_ptrObserver(this)注册了自己。这非常危险因为它创建了一个新的、独立的shared_ptr与可能管理该对象生命周期的外部shared_ptr不共享控制块。这会导致双重删除或内存泄漏。解决方案一使用std::enable_shared_from_this这是标准库提供的安全获取对象自身shared_ptr的工具。// CurrentConditionsDisplay.h (改进版) #include memory class CurrentConditionsDisplay : public Observer, public std::enable_shared_from_thisCurrentConditionsDisplay { // 关键继承 public: // 工厂函数确保对象总是被shared_ptr管理 static std::shared_ptrCurrentConditionsDisplay create(WeatherStation* station) { // 不能直接在构造函数中使用shared_from_this所以用工厂函数 auto ptr std::shared_ptrCurrentConditionsDisplay(new CurrentConditionsDisplay(station)); // 注册时使用正确的shared_ptr if (station) { station-registerObserver(ptr); } return ptr; } // ... 其他成员函数update, display等 ... private: // 构造函数设为私有强制使用工厂函数 explicit CurrentConditionsDisplay(WeatherStation* station) : weatherStation_(station) {} WeatherStation* weatherStation_; // ... };解决方案二主题持有std::weak_ptrObserver让主题持有观察者的弱引用可以避免影响观察者的生命周期并安全地处理观察者已失效的情况。// Subject.h (改进版) #include vector #include memory class Observer; // 前向声明 class Subject { public: virtual ~Subject() default; virtual void registerObserver(std::weak_ptrObserver observer) 0; // 使用weak_ptr virtual void removeObserver(std::weak_ptrObserver observer) 0; virtual void notifyObservers() 0; protected: std::vectorstd::weak_ptrObserver observers_; // 存储weak_ptr }; // WeatherStation.cpp 中 notifyObservers 的实现 void WeatherStation::notifyObservers() { auto it observers_.begin(); while (it ! observers_.end()) { if (auto obs it-lock()) { // 尝试提升为shared_ptr obs-update(this); it; } else { // 观察者对象已不存在从列表中移除失效的weak_ptr it observers_.erase(it); } } }注意事项weak_ptr方案更安全但增加了lock()检查的开销。在实际高频通知的场景下需要权衡性能。通常在观察者数量不多或通知不频繁时weak_ptr是首选。4.2 线程安全考虑如果主题和观察者可能在不同的线程中被访问和修改例如一个线程更新传感器数据另一个线程处理UI更新那么我们的实现就不是线程安全的。observers_向量可能在被遍历时被另一个线程修改导致崩溃。简易的线程安全改造// WeatherStation.h (线程安全版) #include mutex class WeatherStation : public Subject { private: mutable std::mutex mutex_; // 互斥锁保护共享数据 // ... 其他成员 ... public: void registerObserver(std::weak_ptrObserver observer) override { std::lock_guardstd::mutex lock(mutex_); observers_.push_back(observer); } void removeObserver(std::weak_ptrObserver observer) override { std::lock_guardstd::mutex lock(mutex_); // 移除逻辑需要处理weak_ptr的比较略复杂通常需要自定义查找 // 一种方法是存储shared_ptr但用weak_ptr通知这里简化处理 auto it std::find_if(observers_.begin(), observers_.end(), [observer](const std::weak_ptrObserver wp) { return !wp.owner_before(observer) !observer.owner_before(wp); }); if (it ! observers_.end()) { observers_.erase(it); } } void notifyObservers() override { std::vectorstd::weak_ptrObserver observersCopy; { std::lock_guardstd::mutex lock(mutex_); observersCopy observers_; // 复制列表缩短锁持有时间 } for (auto weakObs : observersCopy) { if (auto obs weakObs.lock()) { obs-update(this); // 注意update方法本身也应该是线程安全的 } } } // ... };实操心得这里采用了“复制后通知”的策略在notifyObservers中先复制观察者列表然后释放锁再遍历复制的列表进行通知。这样做的好处是避免了在持有锁的情况下调用未知的update方法从而减少死锁风险并提高了通知过程的并发性。但代价是每次通知都需要复制一次列表。对于观察者数量巨大或通知极其频繁的场景需要更精细的锁策略或无锁数据结构。4.3 性能优化避免不必要的通知有时主题的多个状态可能同时改变或者某些状态的改变对某些观察者没有意义。频繁地、无差别地通知所有观察者会造成性能浪费。优化策略一按事件类型通知为不同的事件定义枚举或标识观察者订阅特定的事件主题只通知对该事件感兴趣的观察者。enum class WeatherEvent { TemperatureChanged, HumidityChanged, PressureChanged, AllChanged }; class Observer { public: virtual void update(Subject* subject, WeatherEvent event) 0; // 增加事件参数 }; class Subject { public: virtual void registerObserver(std::weak_ptrObserver observer, WeatherEvent event) 0; // 需要维护一个 mapWeatherEvent, vectorweak_ptrObserver };优化策略二脏标记与延迟通知主题设置一个“脏”标志位。当状态改变时只标记为“脏”而不立即通知。在一个统一的更新循环比如游戏的主循环中检查所有主题的脏标记如果为“脏”则进行批量通知然后清除标记。这可以将多次连续的状态变更合并为一次通知。class WeatherStation : public Subject { private: bool dataChanged_ false; // ... public: void setMeasurements(float t, float h, float p) { temperature_ t; humidity_ h; pressure_ p; dataChanged_ true; // 只标记不通知 } // 由外部调度器调用 void notifyIfChanged() { if (dataChanged_) { notifyObservers(); dataChanged_ false; } } };5. 模式变体与现代C实践观察者模式有很多“变种”在现代C项目中也常常以不同的面貌出现。5.1 使用std::function与信号槽这是将观察者模式“轻量化”和“现代化”的常用手法。主题不再维护抽象的Observer对象列表而是维护一个std::function回调列表。观察者可以将任何可调用对象函数、lambda表达式、成员函数指针绑定的对象注册为槽。#include functional #include vector class WeatherStation { public: using Callback std::functionvoid(float temp, float humidity, float pressure); void registerCallback(const Callback cb) { callbacks_.push_back(cb); } void setMeasurements(float t, float h, float p) { temperature_ t; humidity_ h; pressure_ p; for (const auto cb : callbacks_) { cb(temperature_, humidity_, pressure_); // “推”模型 } } private: std::vectorCallback callbacks_; float temperature_, humidity_, pressure_; }; // 使用示例 int main() { WeatherStation ws; // 使用lambda注册观察者 auto displayCallback [](float t, float h, float p) { std::cout “Lambda显示: Temp“ t std::endl; }; ws.registerCallback(displayCallback); // 使用std::bind注册成员函数 // 假设有一个Display类 // ws.registerCallback(std::bind(Display::update, myDisplay, std::placeholders::_1, ...)); ws.setMeasurements(20.0f, 50.0f, 1010.0f); return 0; }这种方式极其灵活省去了定义继承体系的麻烦特别适合回调逻辑简单、生命周期明确的场景。许多GUI框架如Qt的信号槽和事件库的核心思想与此类似。5.2 观察者模式与发布-订阅模式很多人会混淆观察者模式和发布-订阅模式。它们确实相似但有一个关键区别耦合度。观察者模式主题和观察者彼此知晓。观察者直接向主题注册。这是一种直接的点对点通信可以看作是“紧耦合”的发布-订阅虽然比硬编码通知要松。发布-订阅模式发布者和订阅者完全不知道对方的存在。它们通过一个中间件事件总线、消息代理进行通信。发布者向某个频道发布消息订阅者订阅感兴趣的频道。中间件负责路由消息。这是更彻底的解耦。在C中你可以实现一个简单的事件总线作为发布-订阅模型的核心#include map #include vector #include functional #include string #include memory class EventBus { using Callback std::functionvoid(const std::string, const void*); // 事件名数据指针 std::mapstd::string, std::vectorCallback subscribers_; public: void subscribe(const std::string eventName, Callback cb) { subscribers_[eventName].push_back(cb); } void publish(const std::string eventName, const void* eventData nullptr) { auto it subscribers_.find(eventName); if (it ! subscribers_.end()) { for (const auto cb : it-second) { cb(eventName, eventData); } } } }; // 任何模块都可以是发布者或订阅者它们只依赖EventBus不互相依赖。6. 实战避坑指南与经验总结结合我多年的项目经验在C中使用观察者模式以下几点至关重要生命周期管理是第一要务这是C资源管理的核心。优先考虑使用智能指针shared_ptr/weak_ptr来管理观察者关系。如果使用原始指针必须建立清晰的“谁创建谁销毁”或“所有者”规则并在析构函数中确保取消注册。忘记在观察者析构时取消注册是导致崩溃的常见原因。警惕通知过程中的修改在主题的notifyObservers方法中遍历观察者列表时如果某个观察者的update方法内部又调用了主题的registerObserver或removeObserver可能会使正在迭代的容器失效如迭代器失效。解决方案可以是先复制列表再通知或者使用标识位延迟处理注册/注销请求。考虑线程安全在多线程环境下对观察者列表的增删改查都必须加锁。同时通知操作本身也可能需要锁但要小心死锁。通常建议像前面示例一样复制列表后释放锁再执行回调。避免过长的调用链与循环依赖观察者的update方法应尽量轻量、快速不要执行耗时操作或产生新的通知否则可能导致通知链过长甚至无限递归。也要小心观察者A通知BB又通知A这种循环依赖。性能与扩展性的权衡如果观察者数量非常多成千上万线性遍历列表进行通知可能成为瓶颈。此时可以考虑按事件类型分组订阅或者使用更高效的数据结构。对于极度性能敏感的场景可能需要寻求观察者模式之外的解决方案。接口设计要稳定Subject和Observer的接口一旦确定应尽量保持稳定。因为修改接口会影响所有实现类。如果后续需要传递更多信息可以考虑使用一个包含事件数据的上下文对象作为参数而不是修改函数签名。观察者模式是一个强大的工具它能显著降低模块间的耦合度。在C中实现它需要你仔细处理内存、线程和性能这些底层细节。从经典的双接口继承实现到现代基于std::function的回调再到引入中间件的发布-订阅其核心思想一脉相承。理解其本质并根据项目具体需求代码规模、性能要求、团队习惯选择最合适的实现变体是一个优秀C工程师的必备能力。下次当你发现代码中到处都是对象间的直接调用时不妨想想是不是该引入一个“观察者”来梳理一下关系了。