设计模式、用Delphi实现---->Decorator 模式

 

 

 

Decorator 模式

起源

Delphi的Decorator模式是在Decorator的基础上进行了扩展。更多Decorator模式的资料请参阅 《设计模式115页》

目的

动态地给一个对象添加一些职责。就增加功能来说，Decorator模式比增加子类更为灵活.

动机

我们经常要为某一些个别的对象增加一些新的职责，并不是全部的类。假设，我们有一组类用来输出文本行。抽象类TtextStream定义了一些接口，而后代如TtextFile、TlinePrinter、TclipboardStream则实现了这些接口。

现在，假设我们想给这些类增加一些新的职责如：文本缓存器、大小定转换、文本分析。

继承机制是添加功能的一种有效途径。从TtextStream类继承了缓存器可以被多个子类的实例使用。但不是很灵活。因为缓存器的选择是静态的了。客户程序不能控制选择缓存器的方式和时机。如此，加重了抽象类TtextStream的字段的负担来控制缓存器，并将带入到它的第一个实例中。通常最好保持高层次的（抽象）基类的轻量。在基类中增加不规则化和原文分析会使它最变得非常笨重！

如果你不想创建一个重量级的基类就会产生别外一个问题。有这样一种情况：大量的独立的继承是可能是，但瀑发式的产生大量的子类来支持不同组合如：TbufTextFile、TscrambledTextFile、TbufScrambledTextFile、TbufLinePrinter、TscrambledLinePrinter及其它。发生同样问题，如果类定义对子类隐藏或不可见的。比如说，如果你想在第三的组件库的高层类中加入一个新的职责，试着给Delphi的Tstream加入一个新的职责！

一个灵活的方法是将文本流嵌入另一个对象中，由这个对象加入缓存器或不规则化。我们称这个嵌入的对象为装饰（Decorator）。这个装饰与文本流组件接口一致，因些它对使用文本流客户程序是透明的。在Delphi中保持接口一致意味着从一个共公的组先继承，例中为TtextStream。