一、 装饰（Decorator）模式

装饰（Decorator）模式又名包装（Wrapper）模式[GOF95]。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。

引言

孙悟空有七十二般变化，他的每一种变化都给他带来一种附加的本领。他变成鱼儿时，就可以到水里游泳；他变成雀儿时，就可以在天上飞行。而不管悟空怎么变化，在二郎神眼里，他永远是那只猢狲。

装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任。换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不使用创造更多子类的情况下，将对象的功能加以扩展。

二、 装饰模式的结构

装饰模式使用原来被装饰的类的一个子类的实例，把客户端的调用委派到被装饰类。装饰模式的关键在于这种扩展是完全透明的。

在孙猴子的例子里，老孙变成的鱼儿相当于老孙的子类，这条鱼儿与外界的互动要通过”委派”，交给老孙的本尊，由老孙本尊采取行动。

装饰模式的类图如下图所示：

在装饰模式中的各个角色有：

• 抽象构件（Component）角色：给出一个抽象接口，以规范准备接收附加责任的对象。
• 具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
• 装饰（Decorator）角色：持有一个构件（Component）对象的实例，并定义一个与抽象构件接口一致的接口。
• 具体装饰（Concrete Decorator）角色：负责给构件对象”贴上”附加的责任。

三、 装饰模式示例性代码

以下示例性代码实现了装饰模式：

// Decorator pattern — Structural example  
using System;

// “Component”
abstract class Component
{
  // Methods
  abstract public void Operation();
}

// “ConcreteComponent”
class ConcreteComponent : Component
{
  // Methods
  override public void Operation()
  {
    Console.WriteLine(“ConcreteComponent.Operation()“);
  }
}

// “Decorator”
abstract class Decorator : Component
{
  // Fields
  protected Component component;

  // Methods
  public void SetComponent( Component component )
  {
    this.component = component;
  }

  override public void Operation()
  {
    if( component != null )
      component.Operation();
  }
}

// “ConcreteDecoratorA”
class ConcreteDecoratorA : Decorator
{
  // Fields
  private string addedState;

  // Methods
  override public void Operation()
  {
    base.Operation();
    addedState = “new state“;
    Console.WriteLine(“ConcreteDecoratorA.Operation()“);
  }
}

// “ConcreteDecoratorB”
class ConcreteDecoratorB : Decorator
{
  // Methods
  override public void Operation()
  {
    base.Operation();
    AddedBehavior();
    Console.WriteLine(“ConcreteDecoratorB.Operation()“);
  }

  void AddedBehavior()
  {
  }
}

/**//// <summary>
/// Client test
/// </summary>
public class Client
{
  public static void Main( string[] args )
  {
    // Create ConcreteComponent and two Decorators
    ConcreteComponent c = new ConcreteComponent();
    ConcreteDecoratorA d1 = new ConcreteDecoratorA();
    ConcreteDecoratorB d2 = new ConcreteDecoratorB();

    // Link decorators
    d1.SetComponent( c );
    d2.SetComponent( d1 );

    d2.Operation();
  }
}

上面的代码在执行装饰时是通过SetComponent方法实现的，在实际应用中，也有通过构造函数实现的，一个典型的创建过程可能如下：

new Decorator1(
   new Decorator2(
      new Decorator3(
         new ConcreteComponent()
         )
      )
   )

装饰模式常常被称为包裹模式，就是因为每一个具体装饰类都将下一个具体装饰类或者具体构件类包裹起来。

四、 装饰模式应当在什么情况下使用

在以下情况下应当使用装饰模式：

1. 需要扩展一个类的功能，或给一个类增加附加责任。
2. 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。

五、 装饰模式实际应用的例子

该例子演示了通过装饰模式为图书馆的图书与录像带添加”可借阅”装饰。

// Decorator pattern — Real World example  
using System;
using System.Collections;

// “Component”
abstract class LibraryItem
{
  // Fields
  private int numCopies;

  // Properties
  public int NumCopies
  {
    get{ return numCopies; }
    set{ numCopies = value; }
  }

  // Methods
  public abstract void Display();
}

// “ConcreteComponent”
class Book : LibraryItem
{
  // Fields
  private string author;
  private string title;

  // Constructors
  public Book(string author,string title,int numCopies)
  {
    this.author = author;
    this.title = title;
    this.NumCopies = numCopies;
  }

  // Methods
  public override void Display()
  {
    Console.WriteLine( “ Book —— “ );
    Console.WriteLine( “ Author: {0}“, author );
    Console.WriteLine( “ Title: {0}“, title );
    Console.WriteLine( “ # Copies: {0}“, NumCopies );
  }
}

// “ConcreteComponent”
class Video : LibraryItem
{
  // Fields
  private string director;
  private string title;
  private int playTime;

  // Constructor
  public Video( string director, string title,
    int numCopies, int playTime )
  {
    this.director = director;
    this.title = title;
    this.NumCopies = numCopies;
    this.playTime = playTime;
  }

  // Methods
  public override void Display()
  {
    Console.WriteLine( “ Video —– “ );
    Console.WriteLine( “ Director: {0}“, director );
    Console.WriteLine( “ Title: {0}“, title );
    Console.WriteLine( “ # Copies: {0}“, NumCopies );
    Console.WriteLine( “ Playtime: {0}“, playTime );
  }
}

// “Decorator”
abstract class Decorator : LibraryItem
{
  // Fields
  protected LibraryItem libraryItem;

  // Constructors
  public Decorator ( LibraryItem libraryItem )
  { this.libraryItem = libraryItem; }

  // Methods
  public override void Display()
  { libraryItem.Display(); }
}

// “ConcreteDecorator”
class Borrowable : Decorator
{
  // Fields
  protected ArrayList borrowers = new ArrayList();

  // Constructors
  public Borrowable( LibraryItem libraryItem )
    : base( libraryItem ) {}

  // Methods
  public void BorrowItem( string name )
  {
    borrowers.Add( name );
    libraryItem.NumCopies—;
  }

  public void ReturnItem( string name )
  {
    borrowers.Remove( name );
    libraryItem.NumCopies++;
  }

  public override void Display()
  {
    base.Display();
    foreach( string borrower in borrowers )
      Console.WriteLine( “ borrower: {0}“, borrower );
  }
}
 
/**//// <summary>
///  DecoratorApp test
/// </summary>
public class DecoratorApp
{
  public static void Main( string[] args )
  {
    // Create book and video and display
    Book book = new Book( “Schnell“, “My Home“, 10 );
    Video video = new Video( “Spielberg“,
      “Schindler’s list“, 23, 60 );
    book.Display();
    video.Display();

    // Make video borrowable, then borrow and display
    Console.WriteLine( “ Video made borrowable:“ );
    Borrowable borrowvideo = new Borrowable( video );
    borrowvideo.BorrowItem( “Cindy Lopez“ );
    borrowvideo.BorrowItem( “Samuel King“ );

    borrowvideo.Display();
  }
}

六、 使用装饰模式的优点和缺点

使用装饰模式主要有以下的优点：

1. 装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
2. 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
3. 这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错。

使用装饰模式主要有以下的缺点：

由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

七、 模式实现的讨论

大多数情况下，装饰模式的实现都比上面定义中给出的示意性实现要简单。对模式进行简化时需要注意以下的情况：

（1）一个装饰类的接口必须与被装饰类的接口相容。

（2）尽量保持Component作为一个”轻”类，不要把太多的逻辑和状态放在Component类里。

（3）如果只有一个ConcreteComponent类而没有抽象的Component类（接口），那么Decorator类经常可以是ConcreteComponent的一个子类。如下图所示：

（4）如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。

八、 透明性的要求

透明的装饰模式

装饰模式通常要求针对抽象编程。装饰模式对客户端的透明性要求程序不要声明一个ConcreteDecorator类型的变量，而应当声明一个Component类型的变量。换言之，下面的做法是对的：

Component c = new ConcreteComponent()；
Component c1 = new ConcreteDecorator1(c)；
Component c2 = new ConcreteDecorator(c1)；

而下面的做法是不对的：

ConcreteComponent c = new ConcreteDecorator()；

这就是前面所说的，装饰模式对客户端是完全透明的含义。

用孙悟空的例子来说，必须永远把孙悟空的所有变化都当成孙悟空来对待，而如果把老孙变成的雀儿当成雀儿，而不是老孙，那就被老孙骗了，而这是不应当发生的。

下面的做法是不对的：

大圣本尊 c = new 大圣本尊()；
雀儿 bird = new 雀儿 (c)；

半透明的装饰模式

然而，纯粹的装饰模式很难找到。装饰模式的用意是在不改变接口的前提下，增强所考虑的类的性能。在增强性能的时候，往往需要建立新的公开的方法。即便是在孙大圣的系统里，也需要新的方法。比如齐天大圣类并没有飞行的能力，而雀儿有。这就意味着雀儿应当有一个新的fly()方法。

这就导致了大多数的装饰模式的实现都是”半透明”（semi-transparent）的，而不是完全”透明”的。换言之，允许装饰模式改变接口，增加新的方法。即声明ConcreteDecorator类型的变量，从而可以调用ConcreteDecorator类中才有的方法：

齐天大圣 c = new 大圣本尊()；
雀儿 bird = new 雀儿(c)；
bird.fly()；

齐天大圣接口根本没有fly()这个方法，而雀儿接口里有这个方法。

九、 装饰模式在.NET中的应用

.net中存在如下类模型：

下面的代码段用来将XmlDocument的内容格式输出。我们可以体会Decorator模式在这里所起的作用。

// 生成ConcreteComponent（内存流ms）
MemoryStream ms = new MemoryStream();

// 用XmlTextWriter对内存流 ms 进行装饰
// 此处使用了半透明的装饰模式
XmlTextWriter xtw = new XmlTextWriter(ms, Encoding.UTF8);
xtw.Formatting = Formatting.Indented;

// 对装饰xtw的操作会转而操作本体－内存流ms
xmlDoc.Save(xtw);

byte[] buf = ms.ToArray();
txtResult.Text = Encoding.UTF8.GetString(buf,0,buf.Length);
xtw.Close();

参考文献：
阎宏，《Java与模式》，电子工业出版社
[美]James W. Cooper，《C#设计模式》，电子工业出版社
[美]Alan Shalloway  James R. Trott，《Design Patterns Explained》，中国电力出版社
[美]Robert C. Martin，《敏捷软件开发－原则、模式与实践》，清华大学出版社
[美]Don Box, Chris Sells，《.NET本质论 第1卷：公共语言运行库》，中国电力出版社