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

看板OOAD作者worldxxi時間12年前 (2013/01/13 07:01)推噓1(1推 0噓 0→)

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

謝謝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://www.ptt.cc/bbs/java/M.1243696485.A.DD1.html -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.25.152.166