HeadFirst 設計模式筆記（二）—— observer

阿新 • • 發佈：2019-01-11

觀察者模式：定義了物件間的一對多依賴，當一個物件有新的訊息，所有與之關聯的物件都將得到通知。這是一個非常常用的模式，它能使我們的物件知悉現狀。就像報社與訂報人之間的關係：

使用者可以隨時決定訂閱或取消訂閱。
一旦使用者訂閱了報紙，那麼新一期的報紙只要一出版就會被送上門。

為了展示這個模式的應用，我們假設有兩個類：Observer和Suject（被觀察者，主題）。

Subject中：

需要維護一個列表，由所有的Observer組成。
實現addObserver/removeObserver實現觀察者的註冊和登出
實現notifyObserver方法，每當出現新的訊息，我們遍歷已註冊的Observer列表，並逐一通知它們（呼叫他們的update方法）

Observer中：

為了把自己註冊到感興趣的Subject上，需要呼叫Subject的addObserver方法，為此可以將Subject作為構造引數，也可以使用其他方法。
實現update方法，供Subject呼叫，即在有新訊息時作何處理。
不再對此Subject感興趣時可以把自己從Subject登出，使用Subject的removeObserver方法。

Java中對觀察者模式提供了內建支援：Obserser類可以實現介面java.util.Observer; Subject類可以擴充套件java.util.Observable類。

注意：java api中提供的這種方式存在一些問題：

Observable是一個類而不是介面，這使得我們不得不通過繼承它來使用，而java是不支援多繼承的，當我們需要另一個基類時這有可能帶來不便。
根據java中的實現，列表中的observer物件被通知的順序是不確定的，我們不能依賴這一順序。

總之，有必要時請自行實現這一模式，它並不太複雜!

PS:通知的傳遞方式有兩種：“推”和“拉”。根據update方法的引數，我們可以選擇把suject作為引數傳給observer，由它自行獲取感興趣的資訊；或者把subject想提供的資訊直接傳給observer。

HeadFirst 設計模式筆記（二）—— observer

觀察者模式：定義了物件間的一對多依賴，當一個物件有新的訊息，所有與之關聯的物件都將得到通知。這是一個非常常用的模式，它能使我們的物件知悉現狀。就像報社與訂報人之間的關係：使用者可以隨時決定訂閱或取消訂閱。一旦使用者訂閱了報紙，那麼新一期的報紙只要一出版就會被送上門。為了展示

HeadFirst 設計模式筆記（七）—— 介面卡模式與外觀模式

介面卡模式（Adapter）：可以想想現實生活中的轉換插頭。介面卡是一箇中間層，能將類的介面轉換成想要的介面。這與前文中的裝飾者模式有點像，不過裝飾者模式是賦予介面新的功能，而介面卡模式則把介面轉換成需要的樣子。我的理解比較簡單：假設我們手頭有兩個介面A和B。有一個

HeadFirst 設計模式筆記（六）—— 命令模式

命令模式所實現的就像餐館裡的“訂單”物件：服務員不需要知道具體的訂單內容，他只需要把訂單物件傳送給廚師就好了！如此一來，服務員與廚師就解耦了。書中舉了個遙控器的例子。遙控器需要控制多種電器的開關操作，比如有電燈和電視機。如果把開啟電燈的操作直接實現在按鈕函式中，那麼電燈與

HeadFirst 設計模式筆記（五）—— 單例模式

singleton pattern 確保一個類只有一個實體，並提供一個全域性訪問點。這就是單例模式的功能。典型的實現： public class Singleton { private static Singleto

HeadFirst 設計模式筆記（四）—— 工廠模式

當我們使用“new”時我們就是在針對實現程式設計，這會使程式碼缺乏彈性。當然我們不可能避免在Java中使用new，真正需要考慮的是系統可能面對的“改變”。我們需要儘量隔離掉可能發生改變的部分。針對實現程式設計時，我們的程式碼中涉及到太多具體類，以後只要我們的系統需要改變，我們就不得不修改大量程

HeadFirst 設計模式筆記（三）—— decorator

裝飾者模式：使用物件組合的方式在執行時給物件賦予新的功能（裝飾），而不是濫用繼承。舉個例子就清晰了：java.io這個包中就應用了這一模式FilterInputStream是一個裝飾者類，它和它的子類可以對InputStream的其他子類進行裝飾。

設計模式筆記（二十一） —— 中介者模式

中介者模式(Mediator)：用一箇中介者物件來封裝一系列的物件互動。中介者物件使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立的改變它們之間的互動。中介者模式很容易在系統中應用，也很容易在系統中誤用。當系統出現了“多對多”互動複雜的物件群時，不要急於使用中介者

設計模式總結（二）

靈活性 mil 一個 blog 以及對象模式結構型設計模式 con 建模設計模式可分為三種：創建型設計模式。結構型設計模式和行為型設計模式。一、創建型設計模式在設計模式中，創建型設計模式處理對象創建過程的設計模式。它依據實際情況來決定詳細如何創建對象。創建型模

設計模式學習（二）“觀察者模式” （C#）

original pan 學習筆記 pri 接口 program date contain 兩個《深入淺出設計模式》學習筆記第二章需求：開發一套氣象監測應用，如圖：氣象站，目前有三種裝置，溫度、濕度和氣壓感應裝置。 WeatherData對象追蹤氣象站的數據，並更

23種設計模式介紹（二）---- 結構型模式

implement weight 代碼介紹定義裝飾器模式大量技術分享記憶由於設計模式篇幅比較大，如果在一篇文章講完所有的設計模式的話不利於閱讀。於是我把它分為三篇文章 23種設計模式介紹（一）---- 創建型模式 23種設計模式介紹（二）---- 結構

Java設計模式簡介（二）：結構型模式

我們接著討論設計模式，上篇文章我講完了5種建立型模式，這章開始，我將講下7種結構型模式：介面卡模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中物件的介面卡模式是各種模式的起源，我們看下面的圖： 6、介面卡模式（Adapter）：介面卡模式將某個

從招式與內功談起——設計模式概述（二）

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

設計模式筆記（一）

設計模式對介面程式設計而不是對實現程式設計優先使用物件組合而不是繼承設計模式的型別建立型模式(Creational Patterns) 結構型模式(Structural Patterns) 行為型模式(Behavioral Patterns)

【設計模式】（二）-附錄A：介面

前言最近發現大話設計模式這本書越往後學越困難了，所以還是非常有必要把附錄A的基礎知識整理整理了。由來為什麼要搞出一個介面來呢？因為C#，JAVE不支援多重繼承，但是同一個類可以實現多個介面。C++支援多重繼承，不用走介面的概念。概念 1.介面是把隱式公共方法和屬

設計模式實現（二）---策略模式、策略模式與簡單工廠模式結合使用

策略模式（Strategy）: 它定義了演算法家族，分別封裝起來，讓它們之間可以互相替換，此模式讓演算法的變化，不會影響到使用演算法的使用者。策略模式大致實現方法 #include <stdio.h> //抽象演算法類 class Strategy { pu

Java設計模式詳談（二）：代理

經過上一篇對於單例模式的心得分享，今天來聊一聊第二種設計模式，關於代理模式的個人理解。代理你可以把它想象成中間人、中介等等，不需要你親自去處理你想做的事，把你想要的告訴他們，讓他們去幫你實現，完成後再把最終的結果通知你。總的來說代理模式分為兩種：一種是靜態代理，一種是動態代理。

Head First設計模式：（二）觀察者模式

通過具體實現一個氣象監測系統來理解觀察者模式此係統的三個部分是氣象站（獲取實際氣象資料的物理裝置）、WeatherData物件（追蹤來自氣象站的資料，並更新佈告板）和佈告板（顯示目前天氣狀況給使用者看）。具體來說該應用需要：利用WeatherDate物件從氣象站取得資料，

雲端計算設計模式翻譯（二）：Circuit Breaker Pattern（斷路器模式）

當連線使用遠端服務或資源時，可能需要花不少精力來做好錯誤處理。這個模式可以有效提高程式的穩定性和彈性。 Context and Problem 在像雲這種分散式的環境中，應用程式的操作經常訪問遠端的資源和服務。然而這類操作有可能因為網路響應慢、超時、資源暫時

Unity中設計模式應用（二）：結合中介者模式的觀察者模式

一.觀察者模式簡介觀察者模式（又被稱為釋出-訂閱（Publish/Subscribe）模式，屬於行為模式的一種，它定義了一種一對多的依賴關係，讓多個觀察者物件同時監聽某一個主題物件。當這個主題物件的狀態發生變化時，會通知所有此狀態的觀察者，這些觀察者會執行相

設計模式深入淺出（二）物件建立——Builder，原型，單例

Builder Builder模式，顧名思義，建造者。這個模式讓我想到了前一段時間的裝修。現在的裝修工程一般是這樣配置的：有一個專案經理，全權由他負責及排程手下的泥工，電工，木工，油漆工的工作。整個裝修階段，泥工，電工等工種會輪流（反覆）進場或中間有些交叉

HeadFirst 設計模式筆記（二）—— observer

相關推薦