Head First 設計模式 —— 02. 觀察者 (Observer) 模式

思考題

在咱們的一個實現中，下列哪一種說法正確？（多選） P42

public class WeatherDate {
    // 實例變量聲明
    
    public void measurementsChanged() {
        float temp = getTemperature();
        float humidity = getHumidity();
        float pressure = getPressure();
        
        currentConditionsDisplay.update(temp, humidity, pressure);
        statisticsDisplay.update(temp, humidity, pressure);
        forecastDisplay.update(temp, humidity, pressure);
    }
    
    // 其餘 WeatherData 方法
}

• [x] A. 咱們是針對具體實現編程，而非針對接口

  • 每一個佈告板都是直接進行更新

• [x] B. 對於每一個新的佈告板，咱們都得修改代碼

  • 每一個新的佈告板，都需加一行更新代碼

• [x] C. 咱們沒法在運行時動態地增長（或刪除）佈告板

  • 沒有針對接口編程，運行時沒法更改佈告板

• [x] D. 佈告板沒有實現一個共同的接口

  • 沒有佈告板的相關介紹，認爲沒有實現同一個接口
  • 後來又學到 TypeScript 和 Golang 等語言，這些語言是存在鴨子類型，不須要顯示繼承類或者接口（但本書全部例子都是 Java ，因此不認爲是鴨子類型）
  • 【答案認爲沒有此選項】全部佈告板都有相同的更新方式，看起來像實現了一個共同的接口

• [x] E. 咱們還沒有封裝改變的部分

  • 佈告板會動態更新，此處還是針對實現編程

• [x] F. 咱們侵犯了 WeatherData 類的封裝

  • 修改了不屬於咱們負責的類
  • 【答案認爲沒有此選項】方法沒有入參，暗示必須在方法內修改

觀察者模式

定義了對象之間的一對多依賴，這樣一來，當一個對象改變狀態時，它的全部依賴者都會受到通知並自動更新 P51

• 設計原則：爲了交互對象之間的鬆耦合設計而努力 P53

  • 鬆耦合把對象之間的互相依賴降到了最低，所以能夠增長彈性，應對變化

所思所想

• 以爲觀察者模式又像用到了策略，不一樣的觀察者和不一樣的主題就相似於不一樣的策略；可能各個不一樣的設計模式都運用到 OO基礎和OO原則，使得有點類似，可是解決的問題仍是有所差別的
• 觀察者模式也用得不少，之前用的各類事件監聽器就是觀察者模式，不過這種模式的觀察者不須要主題的引用，註冊由客戶端實現

本文首發於公衆號：滿賦諸機（ 點擊查看原文） 開源在 GitHub ： reading-notes/head-first-design-patterns