謝謝q大的回覆，但是我還是不太懂，先說一下，我並沒有一定要說我的想法 比較好，只是想了解一下差異，在您比較兩者差異的時候我的想法被當作 不能有輸入，似乎不太公平，如果要比較應該有同樣的立足點，同時，我修改class名稱 讓它看起來比較舒服，我直接修改在下面(引文中修改)。 P.S. 會一直有疑問是因為我總覺得，兩者的結構是完全等價的，但是可以用多型解決的問題 以那麼多前人的經驗不可能硬要弄出新的pattern，所以somehow我的想法一定有缺陷無法 應付變動，而我就是想要知道那個問題是什麼? ※ 引述《qrtt1 (有些事，有時候。。。)》之銘言： : ※ 引述《worldxxi ()》之銘言： : : 今天上課講到decorator pattern，我有個疑問就是，為什麼設計上不寫成這樣 : : abstract class 主餐 : : { : : protect Decorator list; : : abstract public int cost(); : : } : : class 豬排 : 主餐 : : { : : public override int cost() : : { price=130; foreach(decorator in list){ price = decorator.cost(price); } return price; : : } : : } : : ... abstract class Decorator : : { : : } class 味增湯 : Decorator : : { : : public override int cost(price) : : { //handle price return newPrice; : : } : : } : : ... //實際使用長成這樣 main(){ unDecorator = new 某主餐(); unDecorator.addDecorator(new 味增湯); unDecorator.addDecorator(new 優惠時段); : : 那個all list cost在哪邊做先不管，我的意思是UML繼承架構不要讓副食品繼承主餐， : : 而是讓而是用 1--------------* 把主餐與副食品連起來，我覺得這樣更加直覺，但 : : 教授說這兩者完全不同，decorator有pipeline的概念; 而在我的想法中 副食品 變成 : : 互為獨立，失去順序的概念，請問有沒有什麼情況一定要用decorator才能完成的case? : 我想這世上沒有一定得用什麼樣的解法的規則。 : 學習這些『前人』設計上的經驗， : 只是輔助我們在遇到問題時多一個選項可以考慮。 : 依你的想法修改後，問題的複雜點會集中到每一個 : ConcreteComponent 的 behavior， : 也就是 豬排.cost(); : 現在你想得只是單純的『加法』將 list 內的副餐『加』起來那麼單純。 : 如果出現了例外的情況，例如：麥當當晚間，二人同行第二套半價。 : 雖然這個 bussiness logic 不是一種『餐』， : 但毫無疑問的，它的責任落在 cost mehtod！ //ConcreteComponent不動(我的表達不好，這其實是我原本的意思) public int cost() { price = 130; foreach(decorator in list){ price = decorator.cost(price); } return price; } //假設有兩個Decorator裝飾，先用味增湯裝飾，再用優惠裝飾 //味增湯的cost public int cost(price){ //傳進來的price現在是130 return price + 20; } //優惠的cost public int cost(price){ //傳進來的price現在是150 return price * 0.5; } 所以並不會有因為不同情況或需求，導致所有事情的責任都落在 ConcreteComponent的cost上面。 我會說等價的原因是因為在直觀上: 1. 不停用new包裝的過程等於就是讓我想法中的decorator list不斷增加 2. Decorator Pattern在呼叫cost時，是利用繼承架構得知目前要呼叫的 實際上是哪個cost，而我的想法只是明確的指出是誰做。 : 當你有多種 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.25.152.166 ※ 編輯: worldxxi 來自: 140.115.156.63 (01/13 17:05)