Re: [模式] 裝飾者模式(decorator)只有一種結構嗎?

看板OOAD作者qrtt1 (有些事，有時候。。。)時間12年前 (2013/01/12 20:17)推噓1(1推 0噓 1→)

留言2則, 2人參與討論串2/5 (看更多)

※ 引述《worldxxi ()》之銘言： : 今天上課講到decorator pattern，我有個疑問就是，為什麼設計上不寫成這樣 : abstract class 主餐 : { : protect 副食品 list; : abstract public int cost(); : } : class 豬排 : 主餐 : { : public override int cost() : { : return 130 + all list cost; : } : } : ... : abstract class 副食品 : { : } : class 味增湯 : 副食品 : { : public override int cost() : { : return 50; : } : } : ... : 那個all list cost在哪邊做先不管，我的意思是UML繼承架構不要讓副食品繼承主餐， : 而是讓而是用 1--------------* 把主餐與副食品連起來，我覺得這樣更加直覺，但 : 教授說這兩者完全不同，decorator有pipeline的概念; 而在我的想法中副食品變成 : 互為獨立，失去順序的概念，請問有沒有什麼情況一定要用decorator才能完成的case? 我想這世上沒有一定得用什麼樣的解法的規則。學習這些『前人』設計上的經驗，只是輔助我們在遇到問題時多一個選項可以考慮。依你的想法修改後，問題的複雜點會集中到每一個 ConcreteComponent 的 behavior，也就是豬排.cost(); 現在你想得只是單純的『加法』將 list 內的副餐『加』起來那麼單純。如果出現了例外的情況，例如：麥當當晚間，二人同行第二套半價。雖然這個 bussiness logic 不是一種『餐』，但毫無疑問的，它的責任落在 cost mehtod！ public int cost() { price = 130 + all list cost if "麥當當晚間，二人同行第二套半價" in list: return price * 0.5 return price } 當你有多種 ConcreteComponent 要套新的規則時，你都得針對每一個 ConcreteCompoent 去修改它。用 Decorator 你就用裝飾的角度來看它：餐點 = new 優惠時段的(new 含泡菜的(new 含味噌湯的(new 排餐主餐()))) 結帳金額 = 餐點.cost() 對整體來說，只要各別維護不同餐點的單價，與優惠策略的選擇： *. 早餐優惠 *. 晚餐優惠 *. 壽星優惠 *. VIP 優惠 *. 消費總金額優惠 *. 組合套餐優惠動態地多 wrapper 一層上去，維護範圍相較起來單純，會改到的是各別的裝飾者、實體、最終結帳的 caller。整體來說，這比較符合 OCP 原則。學習 design pattern 單純看結構可能沒 fu，但代入了『改變』後，評估怎麼做對『既有』程式影響最小才是我們希望得到的。其它參考文章： http://www.ptt.cc/bbs/java/M.1243696485.A.DD1.html -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.43.113.194 ※ 編輯: qrtt1 來自: 114.43.113.194 (01/12 20:27)