※ 引述《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/cn.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)