谢谢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/cn.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)