觀察者模式

圖 1 (根據《深入淺出設計模式》中文版 page 39 頁圖改)

問題的簡單描述:

設計乙個軟體來顯示氣象站的資料.

系統分析：

1. 系統分析的目標是：將整個系統分解為若干個子系統，確保子系統間要松耦合，子系統內布局要緊湊。

分解方案：

1. 如上圖所示，整個系統分解為三個部分。氣象站、weathe 物件、顯示裝置

2. 整個系統分解為二部分。氣象站、顯示裝置（因為 weather 物件是不是乙個實體，在氣象站和顯示裝置的互動中可以不考慮）

批判方案：

1. 用文字描述的方案總是會遺漏資訊並給人誤導。以上的兩種方案都包括氣象站、顯示裝置。看不出氣象站只是對外表現，增加或移除感應裝置會改變氣象站的內部功能。

2. 以方案1 為例，氣象站和wether 物件，weather物件和顯示裝置間存在介面。在描述中看不出有介面的存在。

發散思維：

1. 假設需求上要求 weather 物件要定時更新

這種需求極容易誤導人（找出這些極具有誤導人的需求不是一件容易的事）

我第一次的設計是讓乙個函式定時地去獲取相關資訊並驅動顯示裝置更新。整個程式過於凸出「定時更新」這一點，而且程式耦合嚴重。如果需求變化為 weather 物件要實時更新。整個程式就要重寫了。

2. 假設需求上要求 weather 物件要實時更新

因為 weather 物件要實時更新，所以採用觀察者模式。程式松耦合，新增新的顯示裝置或感應裝置都很容易。此時如果需求變化為「定時更新」，可以很容易修改程式而不需要整個程式推倒重來。

q1：需求上的「實時更新」和「定時更新」都只是一種具體的更新方式，為什麼沒有把它們當作個某個」未知的更新方式」來處理。如果只將它們考慮為「未知的更新方式」。以後如果需求有變化，那只是和「更新方式」有關的部分需要修改。

q2：就目前的設計方案中，根本沒有「更新方式」部分？

字面上是找不到任何「更新方式」（因為實際上存在，這說明是方案做的不好。大部分的軟體重構都有可能是前期的需求分析的不好，導致許多「xx部分」根本沒有列上去，從而別人忽略）。「顯示方式」本身就該是「weather 物件」和「顯示裝置」間的協議。

q3：做需求和設計軟體，只考慮實體的存在而忽略實體間的互動（只是用一根線表示這個 2 個模組有關係）。對我個人而言，以後要注意不要忽略」非實體的存在「

q4：如果說已經繪出 uml 圖，為什麼程式的設計方案還會如 q1 和 q2 中所討論的那樣，被需求上的某個特定描述所誤導。難道 uml 圖不能告訴我們各個模組的互動方式和關係。為什麼不能根據 uml 圖來設計軟體，而把具體的需求當作是一些實際的策略。

uml 上怎麼樣的連線表示可以採用觀察者，即某種模式的 uml 特徵連線 (可以考慮用軟體來自動生成程式框架)

結構決定功能，高中化學知識！

發散思維2：

圖 2 雲圖

sicp 的 professor 講述了某個關於資料封裝雲圖的故事，然而我是聽了就忘了。

q1. 感應裝置獲取資料，資料經過 weather 物件和顯示裝置最終展示在使用者目前。

假設某天更換了感應裝置的型別，導致獲取資料格式變化。然後每個部分都要修改。

為了避免這種情況。模組間要通過方法互動而不是直接獲取資料（ood 沉思錄中已討論過類的資料要私有）

q2. 顯示格式要變化了，會不會也要修改呢。

圖 3 從感測器到使用者

q3：系統分為多個多個模組，能不能在這些模組都加入透傳中間層。

以後修改**也就是修改中間層或新增中間層（估計在高效能應用場景下，估計是不可能的。但是有多少人的工作和高效能搭邊呢）

觀察者模式的關鍵字：

松耦合、事件驅動、觀察者和訂閱者

設計模式泛泛談：

觀察者模式和非同步**的關係。乙個是模式，另外乙個具體的設計方法

python 中的觀察者模式實現：

用 blinker 庫