※ 引述《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://webptt.com/m.aspx?n=bbs/java/M.1243696485.A.DD1.html --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.43.113.194 ※ 編輯: qrtt1 來自: 114.43.113.194 (01/12 20:27)