2022年2月1日 星期二

[Geroge]設計模式-觀察者模式Observer Pattern (上)

觀察者模式 Observer Pattern

有時候又被稱為 Publish-Subscribe模式(發布訂閱), 模型-視圖(View)模式, 源-收聽者(Listener)模式或從屬者模式, 是軟體設計模式的非常常見一種, 定義對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時, 所有依賴於它的對象都得到通知並被自動更新, 此種模式通常被用來實現事件處理系統







抽象主題角色(subject): 把所有對觀察者對象的飲用保存在一個集合中, 每個抽象主題角色都可以有任意數量的觀察者, 抽象主題提供一個介面, 可以增加和刪除觀察者角色, 一般用一個抽象類和介面來實現

抽象觀察者角色(observer): 為所有具體的觀察者定義一個介面, 在得到主題的通知時更新自己

具體主題角色(concrete subject): 在具體主題內部狀態改變時, 給所有登記過的觀察者發出通知, 具體主題角色通常使用一個子類實現

具體觀察者角色(concrete observer): 該角色實現抽象觀察者角色所要求的更新接口,以便使本身狀態與主題的狀態相協調, 通常用一個子類實現, 如果需要, 具體觀察者角色可以保存一個指向具體主題角色的引用

觀察者模式解決的問題

觀察者模式作為一種設計模式, 就是一種解決問題的方案, 也可以講是一個模板, 方法, 目的就是已通知代替輪詢: 當被觀察者狀態發生改變時, 會觸發觀察者發生改變

解耦觀察者與被觀察者的實現, 觀察者和被觀察對象之間的互動關係不能體現成類之間的直接調用, 否則就將使觀察者和被觀察對象之間緊密的耦合起來, 從根本上違反面向對象的設計原則, 無論是觀察者觀察對象, 還是被觀察者將自己的改變通知觀察者, 都不應該直接調用

例子:

首先先造 觀察者 和 主題角色 的抽象類

觀察者, 會依照觀察狀態而改變

主題角色, 會註冊觀察者, 移除觀察者, 通知觀察者








然後我們在具體主題角色(氣象站)中

有觀察者列表, 其中有註冊觀察者, 移除觀察者和通知觀察者

也有觀察變量, 溫度及濕度, 在變量改變的時候調用通知觀察者

而通知觀察者裡面的方法, 是將註冊在列表中的觀察者一一進行更新的調用














那我們需要觀察者的具體對象, 對變量改變的時候進行反應
















然後運行, 我們先New 出氣象站, 老王, 小李

然後將老王和小李註冊到氣象站中

當溫度或濕度變化的時候, 讓氣象站主動去通知老王和小李






讓氣象站通知老王跟小李就是下面這段程式碼作用











詳細運作, 假設當溫度改變的時候

進行邏輯為: 

氣象站設置溫度>

將註冊列表中的對象更新>

更新中對持有的氣象站進行變量判斷, 若是濕度超過則繼續進行邏輯

https://www.youtube.com/watch?v=cA-vt0Nf1nQ&list=PLGmd9-PCMLhb16ZxeSy00qUsBazXgJyfM&index=19

https://github.com/iw5420/geroge-design-pattern

沒有留言:

張貼留言

[leetcode] [KMP] KMP

ABCDABD... ABCDABF... 簡單的說, 傳統解兩字串匹配部分 可能會來個雙迴圈, 哀個比對, 當不匹配的時候, 會將下方列再後移1位 然後不匹配再後移 然而 如果像上放已經有4個屬於匹配的字串, 她就應該直接往後移四位來匹配, 而不是只移動1位 隱藏的思維是, 當...