[专题讨论]设计模式及应用

decode · 发表于 2003-12-23 22:56

装饰模式(Decorator)
装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。
装饰模式以对客户透明的方式给一个对象加上更多的责任。它可以在不使用创造更多子类的情况下，将对象的功能加以扩展。
装饰模式使用原来被装饰类的一个子类的实例，把客户端的调用委派到被装饰类。装饰模式的关键在于这种扩展是完全透明的。

在装饰模式中参与的角色有：
抽象构件角色：给出一个抽象接口，以规范准备接受附加责任的对象。
具体构件角色：定义一个将要接受附加责任的类。
装饰角色：持有一个构件对象的实例，并定一个一个与抽象构件接口一致的接口。
具体装饰角色，负责给构件对象“贴上”附加的责任。

假设有三个具体装饰类，则一个典型的创建过程如下：
new Decorator1(
new Decorator2(
      new Decorator3(
         new ConcreteComponent()
         )
      )
)
);
这样装饰模式看上去就像一个链表。

装饰模式在什么情况下应该使用
1）需要扩展一个类的功能，或给以各类增加附加责任。
2）需要动态给一个对象增加功能，而这些功能可以再动态撤销。
3）需要增加一些基本功能的排列组合而产生非常大量的功能，从而使得继承关系变得不现实。

使用装饰模式主要有以下优点：
1）和继承关系的目的都是扩展对象的功能，但装饰模式更为灵活
2）通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合
缺点：更容易出错。难于调试。

模式的简化：
在实际实现的时候，模式可能做出一些简化，在这种情况下，应该注意：
1）一个装饰类的接口应该与被装饰类的接口相容。
2）尽量保持抽象构件类是一个“轻“类。构件类主要是提供接口，而不是存储数据。不能将过多的逻辑和状态放置到抽象构件类
3）如果没有抽象构件类，那么装饰类常常是具体构件类的一个子类
4）略去抽象装饰类也是可以的。这样具体装饰类就要扮演双重的角色