1. 項目概述為什么我們需要觀察者模式在C項目里尤其是那些涉及復(fù)雜UI交互、游戲事件系統(tǒng)或者需要解耦業(yè)務(wù)邏輯的場景你是不是經(jīng)常遇到這樣的麻煩一個對象的狀態(tài)改變了得手動去通知一堆其他對象更新代碼里到處都是if (condition) { updateA(); updateB(); ... }牽一發(fā)而動全身維護起來頭大如斗。這就是典型的“緊耦合”問題各個模塊像一團亂麻纏在一起。觀察者模式就是為了解決這個痛點而生的。它是一種行為設(shè)計模式核心思想是定義了一種一對多的依賴關(guān)系。當(dāng)一個對象我們稱之為“主題”或“被觀察者”的狀態(tài)發(fā)生改變時所有依賴于它的對象我們稱之為“觀察者”都會自動得到通知并被更新。你可以把它想象成微信公眾號的訂閱機制你觀察者關(guān)注了某個公眾號主題。公眾號一發(fā)布新文章狀態(tài)改變所有訂閱者觀察者列表的手機就會自動收到推送通知更新回調(diào)而公眾號完全不需要知道具體是誰訂閱了它。對于C開發(fā)者尤其是面臨面試或構(gòu)建中大型項目的朋友深入理解并手寫實現(xiàn)觀察者模式絕不僅僅是背下一個設(shè)計模式的名字。它能讓你從根本上理解如何設(shè)計松耦合、高內(nèi)聚的系統(tǒng)架構(gòu)寫出更靈活、更易擴展的代碼。無論是游戲里的成就系統(tǒng)、UI控件的數(shù)據(jù)綁定還是分布式系統(tǒng)中的事件總線其底層思想都離不開觀察者模式。接下來我們就從思想到代碼徹底拆解這個模式讓你不僅能寫出標(biāo)準(zhǔn)實現(xiàn)更能理解其變種和實戰(zhàn)中的精妙之處。2. 模式思想深度拆解不僅僅是“訂閱-發(fā)布”2.1 核心角色與職責(zé)要理解觀察者模式首先得搞清楚戲臺上的幾個關(guān)鍵角色Subject主題/被觀察者職責(zé)維護一個觀察者對象的列表。提供“添加”、“刪除”和“通知”觀察者的接口。關(guān)鍵點它只知道有一群觀察者在盯著它但完全不知道這些觀察者具體是誰、是干什么的。它只負(fù)責(zé)在自身狀態(tài)變化時遍歷列表調(diào)用每個觀察者的某個約定好的方法比如update。Observer觀察者職責(zé)定義一個更新接口通常是純虛函數(shù)用于接收來自主題的通知。關(guān)鍵點所有具體的觀察者都必須實現(xiàn)這個接口。當(dāng)主題通知時觀察者通過這個接口獲取更新并執(zhí)行自己的業(yè)務(wù)邏輯。觀察者可以訂閱多個不同的主題。ConcreteSubject具體主題職責(zé)繼承或?qū)崿F(xiàn)Subject。它擁有實際的狀態(tài)當(dāng)這些狀態(tài)改變時調(diào)用繼承的“通知”方法。關(guān)鍵點它是觸發(fā)通知的源頭。通常我們會在它的狀態(tài)設(shè)置函數(shù)setState里加入通知邏輯。ConcreteObserver具體觀察者職責(zé)實現(xiàn)Observer接口。保存一個指向ConcreteSubject的引用或指針以便在收到通知時能獲取主題的具體狀態(tài)。關(guān)鍵點它實現(xiàn)了具體的響應(yīng)行為。比如一個UI標(biāo)簽觀察者在收到通知后會去讀取主題的最新數(shù)據(jù)并更新顯示。注意這里有一個經(jīng)典的設(shè)計抉擇——是采用“推”模型還是“拉”模型在“推”模型中主題在通知時會將被改變的數(shù)據(jù)作為參數(shù)傳遞給觀察者。在“拉”模型中主題只發(fā)送一個簡單的通知觀察者收到通知后主動去主題那里“拉取”所需的數(shù)據(jù)。C實現(xiàn)中兩者都很常見推模型更直接拉模型則更靈活觀察者按需索取我們后續(xù)的代碼會展示拉模型因為它更符合松耦合的精神。2.2 模式的價值與適用場景理解了角色我們再來看看這個模式到底好在哪里以及什么時候該用它價值一解耦這是最大的好處。主題和觀察者之間依賴于抽象Subject和Observer接口而非具體實現(xiàn)。你可以獨立地復(fù)用或修改主題或觀察者只要接口不變另一邊就無需改動。價值二支持廣播通信主題不需要指定接收者通知會自動發(fā)給所有觀察者。這在事件處理系統(tǒng)中非常有用。價值三符合開閉原則你可以隨時增加新的觀察者類而無需修改主題的代碼。系統(tǒng)擴展變得非常容易。那么什么場景下你應(yīng)該考慮使用觀察者模式呢GUI事件處理按鈕點擊、鼠標(biāo)移動等事件監(jiān)聽這些事件的控件就是觀察者。數(shù)據(jù)模型與視圖分離MVC/MVVM架構(gòu)中當(dāng)模型主題數(shù)據(jù)變化時多個視圖觀察者需要自動更新。游戲開發(fā)成就系統(tǒng)觀察者監(jiān)聽玩家擊殺、收集等事件、AI系統(tǒng)AI監(jiān)聽玩家位置變化。分布式系統(tǒng)的消息中間件生產(chǎn)者主題發(fā)布消息多個消費者觀察者訂閱并處理。監(jiān)控與日志系統(tǒng)被監(jiān)控的服務(wù)主題狀態(tài)變化觸發(fā)多個日志記錄器、報警器觀察者工作。3. 基礎(chǔ)代碼實現(xiàn)從零搭建一個松耦合系統(tǒng)理論說再多不如一行代碼。我們來實現(xiàn)一個經(jīng)典的例子一個氣象站W(wǎng)eatherStation作為具體主題負(fù)責(zé)收集溫度、濕度數(shù)據(jù)。多個顯示設(shè)備如CurrentConditionsDisplay當(dāng)前狀況顯示板、StatisticsDisplay統(tǒng)計顯示板作為具體觀察者訂閱氣象站的數(shù)據(jù)更新。當(dāng)氣象站數(shù)據(jù)變化時所有顯示板自動更新。3.1 定義觀察者與主題接口這是模式的基石定義了通信的契約。// Observer.h - 觀察者接口 #ifndef OBSERVER_H #define OBSERVER_H // 前向聲明避免頭文件循環(huán)依賴。Observer只需要知道Subject存在不需要知道其細(xì)節(jié)。 class Subject; class Observer { public: virtual ~Observer() default; // 基類虛析構(gòu)函數(shù)確保派生類對象能被正確釋放 // 更新接口。當(dāng)主題狀態(tài)改變時主題會調(diào)用此方法。 // 參數(shù)subject指向狀態(tài)發(fā)生改變的主題對象觀察者可以據(jù)此查詢主題狀態(tài)。 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來管理觀察者的生命周期。這是一個現(xiàn)代C的推薦做法可以避免手動內(nèi)存管理的麻煩和懸空指針的風(fēng)險。主題持有觀察者的智能指針當(dāng)最后一個持有該觀察者的主題被銷毀時觀察者對象也會被自動清理。當(dāng)然如果觀察者的生命周期由其他模塊嚴(yán)格管理使用原始指針或std::weak_ptr也是可行的但shared_ptr在大多數(shù)情況下是最省心的選擇。3.2 實現(xiàn)具體主題氣象站具體主題需要維護狀態(tài)和觀察者列表并在狀態(tài)改變時觸發(fā)通知。// 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) {} // 實現(xiàn)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則直接調(diào)用 obs-update(this); // “拉”模型將自身指針傳給觀察者 } } } // 設(shè)置氣象數(shù)據(jù)并在設(shè)置后自動通知觀察者 void setMeasurements(float temperature, float humidity, float pressure) { temperature_ temperature; humidity_ humidity; pressure_ pressure; measurementsChanged(); // 數(shù)據(jù)改變觸發(fā)更新流程 } // 供觀察者“拉取”數(shù)據(jù)的接口 float getTemperature() const { return temperature_; } float getHumidity() const { return humidity_; } float getPressure() const { return pressure_; } private: // 封裝通知邏輯確保數(shù)據(jù)設(shè)置后必然通知 void measurementsChanged() { notifyObservers(); } }; #endif // WEATHER_STATION_H3.3 實現(xiàn)具體觀察者顯示板觀察者需要在構(gòu)造函數(shù)中訂閱主題并在update方法中做出響應(yīng)。// CurrentConditionsDisplay.h #ifndef CURRENT_CONDITIONS_DISPLAY_H #define CURRENT_CONDITIONS_DISPLAY_H #include “Observer.h” #include “WeatherStation.h” // 需要知道具體主題以獲取數(shù)據(jù) #include iostream class CurrentConditionsDisplay : public Observer { private: // 持有對主題的引用這里用指針用于“拉取”數(shù)據(jù) WeatherStation* weatherStation_; float temperature_; float humidity_; public: // 構(gòu)造函數(shù)中注冊自己到主題 explicit CurrentConditionsDisplay(WeatherStation* station) : weatherStation_(station), temperature_(0.0f), humidity_(0.0f) { if (weatherStation_) { // 注意這里需要將this指針轉(zhuǎn)換為shared_ptr。 // 在實際項目中觀察者對象本身通常也由智能指針管理。 // 這里為了示例簡單假設(shè)Display對象生命周期由外部管理。 // 更安全的做法是讓Display也繼承std::enable_shared_from_this。 weatherStation_-registerObserver(std::shared_ptrObserver(this)); } } ~CurrentConditionsDisplay() override { if (weatherStation_) { // 析構(gòu)時取消注冊防止主題通知一個已銷毀的對象 weatherStation_-removeObserver(std::shared_ptrObserver(this)); } } void update(Subject* subject) override { // 安全轉(zhuǎn)換確保通知來自我們關(guān)心的主題 if (auto ws dynamic_castWeatherStation*(subject)) { temperature_ ws-getTemperature(); humidity_ ws-getHumidity(); display(); } } void display() const { std::cout “[當(dāng)前狀況顯示] 溫度: “ 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); // 更新統(tǒng)計值 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 “[統(tǒng)計顯示] 平均/最高/最低溫度: “ avgTemp_ “°C / “ maxTemp_ “°C / “ minTemp_ “°C” std::endl; } }; #endif // STATISTICS_DISPLAY_H3.4 組裝與運行體驗松耦合的魅力最后我們寫一個簡單的main函數(shù)來驗證整個系統(tǒng)的工作。// main.cpp #include “WeatherStation.h” #include “CurrentConditionsDisplay.h” #include “StatisticsDisplay.h” #include memory int main() { // 1. 創(chuàng)建主題氣象站 WeatherStation weatherStation; // 2. 創(chuàng)建觀察者顯示板并傳入主題進行注冊 CurrentConditionsDisplay currentDisplay(weatherStation); StatisticsDisplay statsDisplay(weatherStation); std::cout “ 第一次數(shù)據(jù)更新 ” std::endl; // 3. 主題數(shù)據(jù)更新自動通知所有觀察者 weatherStation.setMeasurements(25.0f, 65.0f, 1012.0f); std::cout “\n 第二次數(shù)據(jù)更新 ” std::endl; weatherStation.setMeasurements(26.5f, 70.0f, 1011.5f); std::cout “\n 第三次數(shù)據(jù)更新 ” std::endl; weatherStation.setMeasurements(24.0f, 90.0f, 1013.0f); // 4. 觀察者會在每次setMeasurements后自動顯示新數(shù)據(jù) return 0; }運行這個程序你會看到每次調(diào)用weatherStation.setMeasurements后兩個顯示板都會自動打印出最新的信息而氣象站完全不知道顯示板是如何工作的。這就是觀察者模式實現(xiàn)的松耦合通信。4. 進階實現(xiàn)與關(guān)鍵問題剖析上面的基礎(chǔ)實現(xiàn)已經(jīng)揭示了模式的核心但在實際項目中直接這樣用可能會踩坑。我們來深入幾個關(guān)鍵問題并給出更健壯的解決方案。4.1 內(nèi)存管理與生命周期陷阱這是C實現(xiàn)觀察者模式最容易出問題的地方。在上面的示例中我們在CurrentConditionsDisplay的構(gòu)造函數(shù)里用std::shared_ptrObserver(this)注冊了自己。這非常危險因為它創(chuàng)建了一個新的、獨立的shared_ptr與可能管理該對象生命周期的外部shared_ptr不共享控制塊。這會導(dǎo)致雙重刪除或內(nèi)存泄漏。解決方案一使用std::enable_shared_from_this這是標(biāo)準(zhǔn)庫提供的安全獲取對象自身shared_ptr的工具。// CurrentConditionsDisplay.h (改進版) #include memory class CurrentConditionsDisplay : public Observer, public std::enable_shared_from_thisCurrentConditionsDisplay { // 關(guān)鍵繼承 public: // 工廠函數(shù)確保對象總是被shared_ptr管理 static std::shared_ptrCurrentConditionsDisplay create(WeatherStation* station) { // 不能直接在構(gòu)造函數(shù)中使用shared_from_this所以用工廠函數(shù) auto ptr std::shared_ptrCurrentConditionsDisplay(new CurrentConditionsDisplay(station)); // 注冊時使用正確的shared_ptr if (station) { station-registerObserver(ptr); } return ptr; } // ... 其他成員函數(shù)update, display等 ... private: // 構(gòu)造函數(shù)設(shè)為私有強制使用工廠函數(shù) 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 的實現(xiàn) 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()檢查的開銷。在實際高頻通知的場景下需要權(quán)衡性能。通常在觀察者數(shù)量不多或通知不頻繁時weak_ptr是首選。4.2 線程安全考慮如果主題和觀察者可能在不同的線程中被訪問和修改例如一個線程更新傳感器數(shù)據(jù)另一個線程處理UI更新那么我們的實現(xiàn)就不是線程安全的。observers_向量可能在被遍歷時被另一個線程修改導(dǎo)致崩潰。簡易的線程安全改造// WeatherStation.h (線程安全版) #include mutex class WeatherStation : public Subject { private: mutable std::mutex mutex_; // 互斥鎖保護共享數(shù)據(jù) // ... 其他成員 ... 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的比較略復(fù)雜通常需要自定義查找 // 一種方法是存儲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_; // 復(fù)制列表縮短鎖持有時間 } for (auto weakObs : observersCopy) { if (auto obs weakObs.lock()) { obs-update(this); // 注意update方法本身也應(yīng)該是線程安全的 } } } // ... };實操心得這里采用了“復(fù)制后通知”的策略在notifyObservers中先復(fù)制觀察者列表然后釋放鎖再遍歷復(fù)制的列表進行通知。這樣做的好處是避免了在持有鎖的情況下調(diào)用未知的update方法從而減少死鎖風(fēng)險并提高了通知過程的并發(fā)性。但代價是每次通知都需要復(fù)制一次列表。對于觀察者數(shù)量巨大或通知極其頻繁的場景需要更精細(xì)的鎖策略或無鎖數(shù)據(jù)結(jié)構(gòu)。4.3 性能優(yōu)化避免不必要的通知有時主題的多個狀態(tài)可能同時改變或者某些狀態(tài)的改變對某些觀察者沒有意義。頻繁地、無差別地通知所有觀察者會造成性能浪費。優(yōu)化策略一按事件類型通知為不同的事件定義枚舉或標(biāo)識觀察者訂閱特定的事件主題只通知對該事件感興趣的觀察者。enum class WeatherEvent { TemperatureChanged, HumidityChanged, PressureChanged, AllChanged }; class Observer { public: virtual void update(Subject* subject, WeatherEvent event) 0; // 增加事件參數(shù) }; class Subject { public: virtual void registerObserver(std::weak_ptrObserver observer, WeatherEvent event) 0; // 需要維護一個 mapWeatherEvent, vectorweak_ptrObserver };優(yōu)化策略二臟標(biāo)記與延遲通知主題設(shè)置一個“臟”標(biāo)志位。當(dāng)狀態(tài)改變時只標(biāo)記為“臟”而不立即通知。在一個統(tǒng)一的更新循環(huán)比如游戲的主循環(huán)中檢查所有主題的臟標(biāo)記如果為“臟”則進行批量通知然后清除標(biāo)記。這可以將多次連續(xù)的狀態(tài)變更合并為一次通知。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; // 只標(biāo)記不通知 } // 由外部調(diào)度器調(diào)用 void notifyIfChanged() { if (dataChanged_) { notifyObservers(); dataChanged_ false; } } };5. 模式變體與現(xiàn)代C實踐觀察者模式有很多“變種”在現(xiàn)代C項目中也常常以不同的面貌出現(xiàn)。5.1 使用std::function與信號槽這是將觀察者模式“輕量化”和“現(xiàn)代化”的常用手法。主題不再維護抽象的Observer對象列表而是維護一個std::function回調(diào)列表。觀察者可以將任何可調(diào)用對象函數(shù)、lambda表達式、成員函數(shù)指針綁定的對象注冊為槽。#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注冊成員函數(shù) // 假設(shè)有一個Display類 // ws.registerCallback(std::bind(Display::update, myDisplay, std::placeholders::_1, ...)); ws.setMeasurements(20.0f, 50.0f, 1010.0f); return 0; }這種方式極其靈活省去了定義繼承體系的麻煩特別適合回調(diào)邏輯簡單、生命周期明確的場景。許多GUI框架如Qt的信號槽和事件庫的核心思想與此類似。5.2 觀察者模式與發(fā)布-訂閱模式很多人會混淆觀察者模式和發(fā)布-訂閱模式。它們確實相似但有一個關(guān)鍵區(qū)別耦合度。觀察者模式主題和觀察者彼此知曉。觀察者直接向主題注冊。這是一種直接的點對點通信可以看作是“緊耦合”的發(fā)布-訂閱雖然比硬編碼通知要松。發(fā)布-訂閱模式發(fā)布者和訂閱者完全不知道對方的存在。它們通過一個中間件事件總線、消息代理進行通信。發(fā)布者向某個頻道發(fā)布消息訂閱者訂閱感興趣的頻道。中間件負(fù)責(zé)路由消息。這是更徹底的解耦。在C中你可以實現(xiàn)一個簡單的事件總線作為發(fā)布-訂閱模型的核心#include map #include vector #include functional #include string #include memory class EventBus { using Callback std::functionvoid(const std::string, const void*); // 事件名數(shù)據(jù)指針 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); } } } }; // 任何模塊都可以是發(fā)布者或訂閱者它們只依賴EventBus不互相依賴。6. 實戰(zhàn)避坑指南與經(jīng)驗總結(jié)結(jié)合我多年的項目經(jīng)驗在C中使用觀察者模式以下幾點至關(guān)重要生命周期管理是第一要務(wù)這是C資源管理的核心。優(yōu)先考慮使用智能指針shared_ptr/weak_ptr來管理觀察者關(guān)系。如果使用原始指針必須建立清晰的“誰創(chuàng)建誰銷毀”或“所有者”規(guī)則并在析構(gòu)函數(shù)中確保取消注冊。忘記在觀察者析構(gòu)時取消注冊是導(dǎo)致崩潰的常見原因。警惕通知過程中的修改在主題的notifyObservers方法中遍歷觀察者列表時如果某個觀察者的update方法內(nèi)部又調(diào)用了主題的registerObserver或removeObserver可能會使正在迭代的容器失效如迭代器失效。解決方案可以是先復(fù)制列表再通知或者使用標(biāo)識位延遲處理注冊/注銷請求?？紤]線程安全在多線程環(huán)境下對觀察者列表的增刪改查都必須加鎖。同時通知操作本身也可能需要鎖但要小心死鎖。通常建議像前面示例一樣復(fù)制列表后釋放鎖再執(zhí)行回調(diào)。避免過長的調(diào)用鏈與循環(huán)依賴觀察者的update方法應(yīng)盡量輕量、快速不要執(zhí)行耗時操作或產(chǎn)生新的通知否則可能導(dǎo)致通知鏈過長甚至無限遞歸。也要小心觀察者A通知BB又通知A這種循環(huán)依賴。性能與擴展性的權(quán)衡如果觀察者數(shù)量非常多成千上萬線性遍歷列表進行通知可能成為瓶頸。此時可以考慮按事件類型分組訂閱或者使用更高效的數(shù)據(jù)結(jié)構(gòu)。對于極度性能敏感的場景可能需要尋求觀察者模式之外的解決方案。接口設(shè)計要穩(wěn)定Subject和Observer的接口一旦確定應(yīng)盡量保持穩(wěn)定。因為修改接口會影響所有實現(xiàn)類。如果后續(xù)需要傳遞更多信息可以考慮使用一個包含事件數(shù)據(jù)的上下文對象作為參數(shù)而不是修改函數(shù)簽名。觀察者模式是一個強大的工具它能顯著降低模塊間的耦合度。在C中實現(xiàn)它需要你仔細(xì)處理內(nèi)存、線程和性能這些底層細(xì)節(jié)。從經(jīng)典的雙接口繼承實現(xiàn)到現(xiàn)代基于std::function的回調(diào)再到引入中間件的發(fā)布-訂閱其核心思想一脈相承。理解其本質(zhì)并根據(jù)項目具體需求代碼規(guī)模、性能要求、團隊習(xí)慣選擇最合適的實現(xiàn)變體是一個優(yōu)秀C工程師的必備能力。下次當(dāng)你發(fā)現(xiàn)代碼中到處都是對象間的直接調(diào)用時不妨想想是不是該引入一個“觀察者”來梳理一下關(guān)系了。