View
171
Download
6
Category
Preview:
Citation preview
Mediator Pattern
Chain of Responsibility
首先
請各位看兩段程式碼
相信大家一定覺得右邊程式碼比較乾淨….吧
請讓我娓娓道來
其實
故事是這樣的
銷售
庫存採購
銷售
›1.銷售，如果庫存不夠，則通知採購進貨，再行銷售
›2.取得銷售狀況(賣很好，賣很差)
›3.將剩餘商品打折出售
採購
›1.採購商品進庫存
›2.若銷售狀況不好，則採購減半
›3.不再採購商品
庫存
›1.庫存數量增加
›2.庫存數量減少
›3.取得庫存數量
›4.存量過多，通知不要採購，盡快銷售
我把功能擴展了
採購管理
銷售管理庫存管理 資產管理
物流管理
好像有點複雜
這裡提供一個整理的方法
各類別的耦合交給一個類別去處理
採購管理
銷售管理庫存管理 資產管理
物流管理
仲介
將原本的程式改造一下
減少類別間的倚賴，把一對多的倚賴變成了一對一的倚賴，同時也降低了類別間的耦合
仲介者會膨脹得很大，原本N
個物件直接的相互倚賴關係，全轉換為仲介者和各個同事類別的倚賴關係，同事類別越多，仲介者的邏輯就越複雜
用一個仲介者物件封裝一系列的物件交互作用，仲介者使各物件不需要直接地互動，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互作用
中場休息一下
接下來要講
責任鏈
請各位看一下我在地上撿到的code
這麼多IF
怎麼整理?
範例
登入驗證
1 2 3 4
IF => IF => IF => IF
驗證結束 => 交給下一位=> 驗證結束=> 交給下一位=> 驗證結束=> 交給下一位
…………..待續
驗證
下一位
稍微設計一下程式碼
請求和處理分開，請求者可以不用知道是誰處理的，處理者可以不用知道請求的全貌，兩者解耦合，提升系統的靈活性。
責任鏈模式一般是從鏈子的開頭位置進行遍曆，找處理對象，對性能有一定的損耗。
因為採用遞迴的方式，較不易偵錯
使多個物件都有機會處理請求，從而避免請求的發送者和接收者的耦合關系，將這些物件連成一條鏈，並沿着這條鏈傳遞請求，直到有一個物件處理了它為止。
謝謝各位
Recommended