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工程師的必備能力。下次當你發現代碼中到處都是對象間的直接調用時不妨想想是不是該引入一個“觀察者”來梳理一下關系了。