文章目錄

• 案例：文章推送
• 觀察者模式
• • 觀察者模式的運作流程
  • 觀察者模式解決的問題
• 觀察者模式大顯身手
• 總結
• • 要點
  • 應用場景
  • 生產者-消費者模型 VS 觀察者模式
• 完整代碼及文檔

---

案例：文章推送

假設我是一個科幻小說愛好者，我維護著一個叫做ScienceFictionPusher的公眾號，定期向豆瓣、知乎等平臺推送那些我覺得有趣的科幻小說，于是為了方便管理，我的推送程序是這樣的邏輯

class ScienceFictionPusher { public://推送內容void newPush(){//分別向各大平臺推送內容_zhihu->update(_url, _title, _desc);_douban->update(_url, _title, _desc);}//設置新的內容void setNewFiction(const std::string& url, const std::string& title, const std::string& desc){_url = url;_title = title;-_desc = desc;newPush();}private:std::string _url; //小說鏈接std::string _title; //小說名std::string _desc; //小說簡介Douban* _douban;Zhihu* _zhihu; };

上面這種實現方式咋一看沒什么問題，甚至在某些地方處理的還不錯，因為我們將內容的更新從平臺主動的拉取變為了公眾號的主動推送，大大減少了空轉時間。因此，我們將代碼投入使用

隨著粉絲越來越多，公眾號的名氣也越來越大，于是乎越來越多的平臺開始邀請我的專欄入駐，但是此時就出現了問題

如果采用上面這種模式的話，當有大量的平臺時，代碼會是這樣的，存在大量的冗余，可讀性也極差

void newPush() {//分別向各大平臺推送內容_zhihu->update(_url, _title, _desc);_douban->update(_url, _title, _desc);_wechat->update(_url, _title, _desc);_uc->update(_url, _title, _desc);_tiktok->update(_url, _title, _desc);_bilibili->update(_url, _title, _desc);_baidu->update(_url, _title, _desc);_csdn->update(_url, _title, _desc);...........................}

由于公眾號的經營也存在波動，當流量大的時候我們會有新增的平臺，當某個平臺流量小的時候我們也不會再去維護，所以平臺的數量是時刻變化的，那這樣的代碼就意味著我們需要時刻去程序中修改，無法動態的增加、刪除，效率極低。

那有什么好的解決方法嗎？這就到了 觀察者模式出場的時候

---

觀察者模式

觀察者模式也叫做發布訂閱模式，它定義了對象之間的一對多依賴，當一個對象改變狀態的時候，它的所有依賴著都會收到通知并自動更新。

為了方便舉例，這里我們將發布內容的對象稱為主題，接收內容的對象稱為觀察者

觀察者模式的運作流程

此時對象C也想要獲取內容，所以它告訴主題他想要注冊成為觀察者


由于主題發布的內容質量逐漸降低，對象A不再需要訂閱，此時它請求注銷主題


從上面我們可以看到，主題主要做了三件事，注冊、刪除、通知觀察者。而觀察者所做的只是被動的接受主題提供的數據

觀察者模式解決的問題

講了這么多，其實觀察者模式最主要的作用就是讓主題和觀察者松耦合：即這兩個對象雖然互相可以交互，但是它們都不清楚彼此的細節

主題只知道觀察者實現了Observer接口，它并不需要知道觀察者的具體類是誰，也不需要了解它究竟實現了什么，它只需要調用觀察者的update將數據更新過去即可。

同樣的，因為主題依賴的只是實現了Observer接口的對象列表，所以無論我們是對觀察者增加還是刪除，都不會對主題造成影響，主題也不需要為了兼容這些觀察者而去修改代碼。

甚至我們還可以在其他地方獨立的復用主題和觀察者，例如我們新增一個新的主題，又或者是新增一個觀察者，由于二者并非緊耦合，所以不會有任何的影響。

總結一下就是，這種設計將對象之間的互相依賴降到了最低，因此我們的程序具有彈性，能夠應對各種變化。

---

觀察者模式大顯身手

回到上面的問題，當我們的公眾號發布新內容的時候，我們會將這些內容推送到所有的入駐平臺中，這正好就符合上面所說的觀察者模式的場景。此時公眾號充當主題對象，而平臺充當觀察者。

此時完整的關系圖如下

根據上面所提到的內容，我們抽象出具體的主題接口和觀察者接口。為了方便使用不同語言的讀者閱讀，我會盡量少用C++的特性，如果還是有不理解的可以私信或者評論區留言。

主題接口只需要提供必須的注冊、刪除、發布即可

class Subject { public:virtual ~Subject() = default;virtual void registerObserver(Observer*) = 0; //注冊觀察者virtual void removeObserver(Observer*) = 0; //移除觀察者virtual void notifyObservers() = 0; //通知所有觀察者 };

觀察者被動等待主題的數據，所以我們也只提供一個更新接口供主題更新數據

class Observer { public:virtual ~Observer() = default;virtual void update(const std::string& url, const std::string& title, const std::string& desc) = 0; //更新數據 };

考慮到每個平臺獲取到新內容都必定要將其展示出來，而每個平臺展示的方式又有所不同，所以我們將其再抽象為一個接口類，觀察者需要繼承這個類并實現自己的展示方法

class DisplayElement { public:virtual ~DisplayElement() = default;virtual void display() = 0; //顯示數據 };

下面就開始具體實例的實現吧

為了保證不會對同一平臺重復發送，以及后續可能會對某些平臺單獨推送內容，我們使用一個哈希表來存儲所有入駐的平臺

//主題派生子類 class ScienceFictionPusher : public Subject { public://增加觀察者void registerObserver(Observer* observer){_observers.insert(observer);}//刪除觀察者void removeObserver(Observer* observer){_observers.erase(observer);}//向所有平臺推送內容void notifyObservers(){for(const auto& ob : _observers){ob->update(_url, _title, _desc);}}//推送新內容void newPush(){notifyObservers();}//設置新內容，當有新內容發布的時候，就會自動推送給所有的平臺void setNewFiction(const std::string& url, const std::string& title, const std::string& desc){_url = url;_title = title;_desc = desc;newPush();}private:std::string _url; //小說鏈接std::string _title; //小說名std::string _desc; //小說簡介std::unordered_set<Observer*> _observers; //入駐的平臺 };

當有新的平臺想要入駐的時候，它只需要繼承觀察者類并實現update接口即可，同時由于我們接收新內容后還需要在自身平臺中顯示，所以還需要繼承發布內容類，并實現display接口

為了方便注冊和刪除觀察者，我們需要保存一個指向主題的指針

//觀察者派生子類 class Zhihu : public Observer, public DisplayElement { public:Zhihu(Subject* ScienceFictionPusher): _ScienceFictionPusher(ScienceFictionPusher){_ScienceFictionPusher->registerObserver(this);}~Zhihu(){_ScienceFictionPusher->removeObserver(this);}//實現更新接口，讓主題主動推送數據void update(const std::string& url, const std::string& title, const std::string& desc){_url = url;_title = title;_desc = desc;display();}//在平臺中顯示推送的內容void display(){std::cout << "知乎每日書籍推薦：" << std::endl;std::cout << "鏈接：" << _url << std::endl;std::cout << "標題：" << _title << std::endl;std::cout << "簡介：" << _desc << "\n" <<std::endl; }private:std::string _url; //小說鏈接std::string _title; //小說名std::string _desc; //小說簡介Subject* _ScienceFictionPusher; //主題對象，方便注冊和刪除 };

其他的觀察者也類似，為了節省篇幅這里就不多寫了，下面寫個簡單的程序測試一下

int main() {ScienceFictionPusher* _subject = new ScienceFictionPusher;Douban* douban = new Douban(_subject);Zhihu* zhihu = new Zhihu(_subject);_subject->setNewFiction("www.aaaaaaa.com", "三體", "作品講述了地球人類文明和三體文明的信息交流、生死搏殺及兩個文明在宇宙中的興衰歷程。");_subject->setNewFiction("www.bbbbbbb.com", "球形閃電", "描述了一個歷經球狀閃電的男主角對其歷盡艱辛的研究歷程，向我們展現了一個獨特、神秘而離奇的世界");delete zhihu;delete douban;delete _subject;return 0; }

我們添加了知乎和豆瓣兩個觀察者，并且連續推送了三體和球形閃電這兩條內容

可以看到，測試結果沒有問題

---

總結

要點

• 觀察者模式定義了對象之間一對多的關系
• 觀察者模式使得我們可以獨立地改變主題與觀察者，從而使二者之間的依賴關系達致松耦合。
• 主題發送通知時，需要遍歷觀察者，因此其知道觀察者的存在
• 觀察者自己決定是否需要訂閱通知，主題對象對此一無所知。

---

應用場景

觀察者模式應該可以說是應用最多、影響最廣的模式之一，它通常應用于游戲引擎、GUI、郵件訂閱等場景

場景1 ：游戲中的事件監控

例如我們設計了一個RPG游戲，當我們的角色移動到敵人的視野范圍時，周圍的敵人就會向角色移動并且發起攻擊。當我們移動到陷阱的觸發位置時，陷阱就會對我們造成傷害。當我們移動到泉水時，泉水又會為角色提供治療或者BUFF。

在上面的例子中，我們的角色就是一個主題，而泉水、陷阱、敵人這些就是觀察者，當我們做出了某種舉動的時候，就會通知它們這些事件的發生，它們就會做出一個具體的響應。這樣就能夠保證事件實時的同步，以及方便我們進行拓展，后續向增加新事件例如減速的泥潭等內容只需要將其注冊為觀察者并實現邏輯即可。

場景2：GUI界面的事件偵聽

在GUI界面中，通常有著許多的選項， 而在這些選項背后，通常又有多個負責不同功能的偵聽者等待我們的結果，當我們按下這個按鈕的時候，就會通知負責這一功能的一系列偵聽者響應號召，執行它們各自的工作，這也是一種觀察者模式

---

生產者-消費者模型 VS 觀察者模式

說到數據的生產和發布、解耦合這兩方面，那就難免要提到生產者消費者模型，下面給出它們兩個的對比圖。

如果不了解生產者消費者模型的可以參考我的往期博客
操作系統：生產者消費者模型的兩種實現（C++）


相同點

• 主要作用都是解耦合
• 兩者都是行為模式，本質上都是發布-消費兩個行為

不同點

• 觀察者模式是一對多，一條消息可以被多個觀察者使用
• 生產者-消費者模型是多對多的，并且一條消息只能被一個消費者使用
• 觀察者模式可以同步實現，也可以異步實現
• 生產者消費者模式依賴于交易場所，只能異步實現
• 觀察者模式中主題知道觀察者的存在，因為它需要遍歷訂閱列表發送通知，因此兩者之間還是存在微弱的耦合關系
• 生產者和消費者借助交易場所(中間隊列)，它們只需要往隊列中生成/消費數據，因此不需要知道對方的存在，屬于完全解耦

---

完整代碼及文檔

如果有需要完整代碼或者markdown文檔的同學可以點擊下面的github鏈接
github

總結

以上是生活随笔為你收集整理的趣谈设计模式 | 观察者模式(Observer) ：消息的发布与订阅的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。