設計模式-行爲型-觀察者模式（OBSERVER）

　　接下來咱們討論一個最難被正確使用也是在框架設計中最容易被誤用的設計模式，觀察者模式。

　　」定義對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時, 全部依賴於它的對象都獲得通知並被自動更新「

　　

　　上圖是觀察者模式的結構類圖，乍一看會被這個設計模式的結構類圖給嚇個不輕。筆者想說結合這個結構的定義，一點一點跟着筆者一點一點梳理，你會很快茅塞頓開。

　　關於該設計模式的定義，咱們能夠添加一些詞讓他更好被理解。」定義對象間的一種一（被觀察者）對多（觀察者）的依賴關係,當一個對象（被觀察者）的狀態發生改變時, 全部依賴於它的對象（觀察者）都獲得通知並被自動更新「。如此一來這個定義就好被理解了。全部觀察者在由於被觀察者的狀態發生改變時收到通知。接下來咱們一步一步分析結構類圖，類圖中的Subject系列的類就是被觀察者，而Observer系列的類就是觀察者。咱們先看被觀察者，被觀察者維護了一個存儲觀察者的數據結構，這個數據結構多是鏈表、數組或是其餘數據結構。被觀察者經過Attach接口添加觀察者，經過Dettach接口刪除觀察者。在被觀察者對象的狀態發生改變經過調用Subject父類的notify方法來通知到全部的已註冊的Observer。通知Observer的方式是經過調用Observer的Update接口，這裏須要注意的Update接口的調用方法，筆者注意到這裏的類結構圖只標註了一種方式。讓咱們回顧一下策略模式（STRATEGY）,Context把有關算法的實現委託給了Strategy，調用Strategy時候有兩種方式一種是推模式一種是拉模式。這裏的類結構圖是屬於拉模式。固然也可使用推模式，既是經過往Update傳入參數來通知Observer。兩種方式都各有各得好處，具體請參見筆者對於這兩種實現模式的總結。

　　這個設計模式的好處以及缺點體如今那些方面呢？

　　1. 第一個被觀察者與觀察者是彼此隔離的，被觀察者不清楚觀察者是誰（被觀察者只有觀察者的指針，而不知道觀察者是屬於哪一個子類），這樣帶來的好處是觀察者極容易被拓展，後續程序員的工做只是新增長一個觀察者的子類。因此這樣的觀察者與被觀察者之間的耦合被固定在了相對固定的抽象層階段。

　　2. 廣播通訊，注意到整個通知方式是一對多的通知全部的觀察者，因此觀察者模式提供了相似於廣播通訊的通知。注意到在拉模式的實現中，每一個觀察者其實是擁有被觀察者的引用的，因此每一個觀察者都有觸發這種廣播通知的能力，正是這一類型的特性，有些廣播的通知可能給系統帶來很難被追蹤的結果。