設計模式之觀察者模式, 個人感覺相當的重要，設計模式觀察者
原文地址:點擊就送
觀察者模式: (又被成為發布訂閱模式, 模型-視圖模式, 源-收聽者模式或從屬者模式) 是軟體設計模式的一種. 在這種模式中, 一個目標物件管理所有依賴於他的觀察者物件, 並且在它本身的狀態改變時, 主動發出通知. 這通常透過呼叫各觀察者所提供的方法來實現. 此種模式通常被用來視作事件處理系統.
UML
在jdk中有 觀察者模式的例子
- Observer觀察者介面
- 被觀察者類 Observable
- 被觀察者發生改變時會通知觀察者
觀察者模式: 總體上被分為兩種
- 發布-訂閱類的問題處理
- 事件驅動模型: 類似web開發的監聽器
- ps:補充一下序列化 key 地址改變, 反序列不會調用構造等
事件驅動模型
- jdk中內建 EventListener 事件監聽介面
- 其中的 Object被transient修飾 ps序列化的相關知識
這兩種代碼上的區別
- 發布訂閱: 被觀察者需要繼承Observable, 觀察者需要實現Observer
- 事件驅動模型: 主動方需要實現 WriterListener[]
總結:
- 這兩種模型達到的效果看上去是一樣的, 觀察者模式更加貼近現實業務, 事件驅動比觀察者不用的地方
- 觀察者模式中理論上針對被觀察者的動作是唯一的, 儘管update中有兩個參數 一個是對象 一個算是標識, 在監聽者模式中算是自訂的 - 注意點實際動作都是由監聽者來實現的, 被監聽者調用
- 事件驅動更加的靈活, 但是系統複雜度作為代價, 也就是由事件來源自己來維護監聽隊列
- 觀察者模式的局限性: 如果被觀察者原來就有父類, 儘管可以用適配器模式, 但是事件驅動事件來源的監聽列表是自己維護的
- 觀察者模式中, 只能用update來觸發對應的操作, 儘管有第二個參數作為雙方約定, 事件驅動的資訊都是封裝在event中由監聽者自己來定義, 監聽者明白自己想要什麼
文中最後舉了一個類子, 感冒了腦袋有點暈,自我總結下
- button是觸發事件的媒介, 需要註冊點擊事件(監聽+具體實現), 比如雙擊這個操作, 使用者雙擊, 事件發生
整個觀察者模式主要分為兩大塊
- 觀察者模式: 發布--訂閱, 變化--更新
- 事件驅動模型: 請求--響應, 事件發生--事件處理
- 也就是應用情境經典代表作者與讀者, 按鈕事件
進度還有 75% fight
