Programming 版 (精华区)

发信人: Sun (大灯泡), 信区: SoftEng
标  题: [Design Pattern] Decorator
发信站: 哈工大紫丁香 (2001年03月22日09:15:47 星期四), 站内信件

发信人：Crystal_Y (小衲)  版面名称：SoftEng(925)
标　题：[Design Pattern] Decorator
发信站：中国科大BBS站 (Wed, 21 Mar 2001 13:04:51 )
标　记：精华
 （Decorator还是有用的呵呵）
　Decorator又是一个对象组合优越于类继承的例子

　当不想对一个ConcreteComponent的代码再作修改，而依然想对它增加
一些额外的功能时（即所谓修饰），可以用Decorator。为了保证系统其它
部分（即使用ConcreteComponent的client部分）不受影响，Decorator和
ConcreteComponent拥有同一个基类Component，Decorator里面
compose了一个component对象，这个component，有可能是那个被修饰
的ConcreteComponent，也有可能是另一个Decorator（有点像Composite
结构）。在原先创建ConcreteComponent的地方，变成创建一个
Decorator，而把ConcreteComponent或者另一个Decorator当作它的数据
成员塞进去。在client需要使用ConcreteComponent各个方法的地方，依
旧不变，只是实际情况下，Decorator首先截获了这些调用，与它无关的，
则传递给它的那个数据成员component；有关的，则先作自己的处理，达
到修饰的效果（更像一个Filter吧呵呵）。

　 设计一个ConcreteComponent的时候，我们关心它的Specfication以及
实现这个Specification需要的东西。如果一个TextView的Specification中没
有提到什么border, scrollbar，我们就没有必要在它里面实现
border,scrollbar。当一种带有border的TextView的需求出现的时候，我们
可以继承一个BorderTextView（或者叫做StyledTextView）来实现它的种
种外观；我们也可以用一个BorderDecorator，嵌套一个
ScrollBarDecorator，最里面包含一个TextView来实现。采用前者的方
法，肯定会出现windows那种BORDER | SCROLL_BAR | ...很多style组合
的调用，这种方式也是可以的呵呵，只是那样会要求你一开始就要考虑到
很多style了，而在一开始，头脑里的事情越少越好~

　　由于Decorator的接口和Component的接口是一致的，所以如果
Component本身就很复杂，采用Decorator的确不划算，因为Decorator无
法共享，在运行时刻会有很多Decorator的实例，这几个组合一下修饰这个
component，那几个又修饰那个，都是heavyweight的话，开销很大，是
一种浪费。heavyweight，lightweight是针对类里面的数据成员多少而言。

　 Composite与Strategy最大的不同，我觉得不是GoF里讲的skin和gut的
区别，而是设计先后的区别，如果在设计TextView的时候就有border的考
虑，那么就可以用Strategy。



--
    太阳当空照，灯泡呵呵笑，
    mm说，早上好，你为什么又不理我了？
    我要做光光，光光没烦恼，
    高高跳，大声叫，光光的乐趣你们不知道！

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: sunner.hit.edu.cn]