→ mars90226 :推! 01/12 22:10
推 BigLoser : 這篇易懂! 09/01 21:04
※ 引述《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)