關於Observer模式不得不說的二三事

今天有同事問我關於observer模式的乙個問題，說觀察者(observer)為什麼要依賴於主題(subject)，如下圖所示：

從上圖可以看出，具體的觀察者對具體的主題有乙個依賴，而且從jdk本身提供的observer介面，我們也可以看到，確實對主題（在jdk的實現中，為observable介面）有乙個依賴，如**所示：

public inte***ce observer

這個是為什麼呢，為什麼這裡會依賴主題物件？其實這個跟subject與observer之間通訊的方式有關，當subject本身狀態發生變化時，會去通知註冊了的observer（即呼叫每個observer的update()方法）,那麼這個時候，主題本身要怎麼樣去給observer傳輸其需要的資料呢？

在我們看到的大多數觀察者的實現中，主題（subject）在通知註冊的observer時，都會把observer所需要的資料封裝好，傳給observer，這個也就是所謂的『推』的模式，主題主動將資料推給觀察者，這種情況下，observer的介面往往定義如下：

public inte***ce observer

在這種『推』的模式下，觀察者本身是不依賴於主題物件的。但還有另外一種所謂『拉』的通訊方式，是指觀察者在需要資料的時候主動從主題物件中獲取，這個情況下面就會出現觀察者依賴於主題物件，

public inte***ce observer

由於這種拉的實現方法出現的比較少，而且『拉』資料的模式有乙個比較大的缺點，那就是出現了主題物件和觀察者物件之間的迴圈依賴，處理不好則很容易出來死迴圈。

但是對於乙個完整的觀察者模式來說，這兩種資料傳輸的方式都是需要的，這也就是jdk的observer介面中的update()方法要有兩個引數的原因（obervable物件一般對應於拉模式，object物件一般對應於推模式），如果你做過swing程式設計，你會發現在swing的事件處理中，listner（實際上就是observer）所接受的引數也支援推拉兩種資料方式，如

public inte***ce mouselistener extends eventlistener

這裡的mouseevent物件實際上也包含了資料**物件（觸發事件的物件），即具體主題物件，而除了主題物件之外的其他屬性，我們都可以看成是推模式中所傳的資料。

好了，解決了同事了疑問，還需要點明observer模式的另一職責。由於我們大多數的observer模式的實現都很簡單，在這樣的實現下，主題物件大多只擁有乙個職責，那就是管理observer的職責（包括通知observer），

class concretesubject implement isubject
public void removeobserver(observer obs)
public void notifyobservers(object obj)
}

加上observer模式是為了解決一對多的關係，久而久之，導致大多數人都忘記了主題物件（subject）本身還應該有另乙個職責，管理observer只是主題（subject）物件應有的共同的職責，不要忘了，還有多主題物件這麼一回事。舉個以前看到的例子，

假設我們的主題物件需要從遠端獲取一些資料，並分別的將其記錄在db中，和顯示在screen上，那麼套用observer模式，可以表示為：

其中，dbobserver將拿到的資料寫到db中，而displayobserver將拿到的資料顯示在screen上，而messagessubject則有了兩個職責，乙個是我們前面說的管理observer的職責，另乙個是去遠端取資料的職責，而這個我認為才是主題物件（subject）應該有的具體的職責。

public class messagessubject extends abstractsubject implements runnable

完成乙個完整的observer模式很難，考慮的東西比較多（光是通知observer這部分就有幾種不同的實現方式），不推薦每次都需要實現乙個很完整的observer模式，但是我們不應該遺忘這些構成完整observer模式鎖需要的部分。

關於Observer模式不得不說的二三事

關於基礎，不得不說

不得不寫點VB程式

不得不說的「跳槽」

關於Observer模式不得不說的二三事

關於基礎，不得不說

不得不寫點VB程式

不得不說的「跳槽」

相關推薦