UML软件工程组织
.NET设计模式研究之装饰模式
作者：terrylee
　　在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？这就是本文要讲的Decorator模式。

　　意图

　　动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。[GOF 《设计模式》]

　　结构图



图1 Decorator模式结构图

　　生活中的例子

　　装饰模式动态地给一个对象添加额外的职责。不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。



图2 使用有画框的画作为例子的装饰模式对象图

　　装饰模式解说

　　在软件开发中，经常会遇到动态地为一个对象而不是整个类增加一些功能的问题，还是以我惯用的记录日志的例子来说明吧（也许在Decorator模式里面用这个例子不是特别合适）。现在要求我们开发的记录日志的组件，除了要支持数据库记录DatabaseLog和文本文件记录TextFileLog两种方式外，我们还需要在不同的应用环境中增加一些额外的功能，比如需要记录日志信息的错误严重级别，需要记录日志信息的优先级别，还有日志信息的扩展属性等功能。在这里，如果我们不去考虑设计模式，解决问题的方法其实很简单，可以通过继承机制去实现，日志类结构图如下：



图3

　　实现代码如下：

　
public abstract class Log
{
　public abstract void Write(string log);
}

public class DatabaseLog : Log
{
　public override void Write(string log)
　{
　　//......记录到数据库中
　}
}

public class TextFileLog : Log
{
　public override void Write(string log)
　{
　　//......记录到文本文件中
　}
}

　　需要记录日志信息的错误严重级别功能和记录日志信息优先级别的功能，只要在原来子类DatabaseLog和TextFileLog的基础上再生成子类即可，同时需要引进两个新的接口IError和I Priority，类结构图如下：



图4

　　实现代码如下：

　
public interface IError
{
　void SetError();
}

public interface IPriority
{
　void SetPriority();
}

public class DBErrorLog : DatabaseLog, IError
{
　public override void Write(string log)
　{
　　base.Write(log);
　}
　public void SetError()
　{
　　//......功能扩展，实现了记录错误严重级别
　}
}

public class DBPriorityLog : DatabaseLog, IPriority
{
　public override void Write(string log)
　{
　　base.Write(log);
　}
　public void SetPriority()
　{
　　//......功能扩展，实现了记录优先级别
　}
}

public class TFErrorLog : TextFileLog, IError
{
　public override void Write(string log)
　{
　　base.Write(log);
　}
　public void SetError()
　{
　　//......功能扩展，实现了记录错误严重级别
　}
}

public class TFPriorityLog : TextFileLog, IPriority
{
　public override void Write(string log)
　{
　　base.Write(log);
　}
　public void SetPriority()
　{
　　//......功能扩展，实现了记录优先级别
　}
}

　　此时可以看到，如果需要相应的功能，直接使用这些子类就可以了。这里我们采用了类的继承方式来解决了对象功能的扩展问题，这种方式是可以达到我们预期的目的。然而，它却带来了一系列的问题。首先，前面的分析只是进行了一种功能的扩展，如果既需要记录错误严重级别，又需要记录优先级时，子类就需要进行接口的多重继承，这在某些情况下会违反类的单一职责原则，注意下图中的蓝色区域：



图5

　　实现代码：

　
public class DBEPLog : DatabaseLog, IError, IPriority
{
　public override void Write(string log)
　{
　　SetError();
　　SetPriority();
　　base.Write(log);
　}
　public void SetError()
　{
　　//......功能扩展，实现了记录错误严重级别
　}
　public void SetPriority()
　{
　　//......功能扩展，实现了记录优先级别
　}
}

public class TFEPLog : DatabaseLog, IError, IPriority
{
　public override void Write(string log)
　{
　　SetError();
　　SetPriority();
　　base.Write(log);
　}
　public void SetError()
　{
　　//......功能扩展，实现了记录错误严重级别
　}
　public void SetPriority()
　{
　　//......功能扩展，实现了记录优先级别
　}
}

　
　　其次，随着以后扩展功能的增多，子类会迅速的膨胀，可以看到，子类的出现其实是DatabaseLog和TextFileLog两个子类与新增加的接口的一种排列组合关系，所以类结构会变得很复杂而难以维护，正如象李建忠老师说的那样“子类复子类，子类何其多”；最后，这种方式的扩展是一种静态的扩展方式，并没有能够真正实现扩展功能的动态添加，客户程序不能选择添加扩展功能的方式和时机。

　　现在又该是Decorator模式出场的时候了，解决方案是把Log对象嵌入到另一个对象中，由这个对象来扩展功能。首先我们要定义一个抽象的包装类LogWrapper，让它继承于Log类，结构图如下：



图6

　　实现代码如下：

　
public abstract class LogWrapper : Log
{
　private Log _log;
　public LogWrapper(Log log)
　{
　　_log = log;
　}
　public override void Write(string log)
　{
　　_log.Write(log);
　}
}

　　现在对于每个扩展的功能，都增加一个包装类的子类，让它们来实现具体的扩展功能，如下图中绿色的区域：



图7

　　实现代码如下：

　
public class LogErrorWrapper : LogWrapper
{
　public LogErrorWrapper(Log _log)
　:base(_log){}

　public override void Write(string log)
　{
　　SetError(); //......功能扩展
　　base.Write(log);
　}

　public void SetError()
　{
　　//......实现了记录错误严重级别
　}
}

public class LogPriorityWrapper : LogWrapper
{
　public LogPriorityWrapper(Log _log): base(_log){}

　public override void Write(string log)
　{
　　SetPriority(); //......功能扩展
　　base.Write(log);
　}

　public void SetPriority()
　{
　　//......实现了记录优先级别
　}
}

　　到这里，LogErrorWrapper类和LogPriorityWrapper类真正实现了对错误严重级别和优先级别的功能的扩展。我们来看一下客户程序如何去调用它：

　
public class Program
{
　public static void Main(string[] args)
　{
　　Log log = new DatabaseLog();
　　LogWrapper lew1 = new LogErrorWrapper(log);

　　//扩展了记录错误严重级别

　　lew1.Write( "Log Message");
　　LogPriorityWrapper lpw1 = new LogPriorityWrapper(log);

　　//扩展了记录优先级别

　　lpw1.Write( "Log Message");
　　LogWrapper lew2 = new LogErrorWrapper(log);
　　LogPriorityWrapper lpw2 = new LogPriorityWrapper(lew2); //这里是lew2

　　//同时扩展了错误严重级别和优先级别

　　lpw2.Write( "Log Message");
　}
}

　　注意在上面程序中的第三段装饰才真正体现出了Decorator模式的精妙所在，这里总共包装了两次：第一次对log对象进行错误严重级别的装饰，变成了lew2对象，第二次再对lew2对象进行装饰，于是变成了lpw2对象，此时的lpw2对象同时扩展了错误严重级别和优先级别的功能。也就是说我们需要哪些功能，就可以这样继续包装下去。到这里也许有人会说LogPriorityWrapper 类的构造函数接收的是一个Log对象，为什么这里可以传入LogErrorWrapper对象呢？通过类结构图就能发现，LogErrorWrapper类其实也是Log类的一个子类。

　　我们分析一下这样会带来什么好处？首先对于扩展功能已经实现了真正的动态增加，只在需要某种功能的时候才进行包装；其次，如果再出现一种新的扩展功能，只需要增加一个对应的包装子类（注意：这一点任何时候都是避免不了的），而无需再进行很多子类的继承，不会出现子类的膨胀，同时Decorator模式也很好的符合了面向对象设计原则中的“优先使用对象组合而非继承”和“开放-封闭”原则。
　
　　.NET 中的装饰模式

　　1．.NET中Decorator模式一个典型的运用就是关于Stream，它存在着如下的类结构：



图8

　　可以看到， BufferedStream和CryptoStream其实就是两个包装类，这里的Decorator模式省略了抽象装饰角色（Decorator），示例代码如下：

　
class Program
{
　public static void Main(string[] args)
　{
　　MemoryStream ms =new MemoryStream(new byte[] { 100,456,864,222,567});

　　//扩展了缓冲的功能

　　BufferedStream buff = new BufferedStream(ms);

　　//扩展了缓冲，加密的功能

　　CryptoStream crypto = new CryptoStream(buff);
　}
}

　　通过反编译，可以看到BufferedStream类的代码（只列出部分），它是继承于Stream类：

　
public sealed class BufferedStream : Stream
{
　// Methods

　private BufferedStream();
　public BufferedStream(Stream stream);
　public BufferedStream(Stream stream, int bufferSize);
　// Fields

　private int _bufferSize;
　private Stream _s;
}


　　2．在Enterprise Library中的DAAB中有一个DbCommandWrapper的包装类，它实现了对IDbCommand类的包装并提供了参数处理的功能。结构图如下：



图9

　　示意性代码如下：

　
public abstract class DBCommandWrapper : MarshalByRefObject, IDisposable
{}

public class SqlCommandWrapper : DBCommandWrapper
{}

public class OracleCommandWrapper : DBCommandWrapper
{}
　

　　效果及实现要点

　　1．Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明，换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能。

　　2．Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象。

　　3．Decortor模式并非解决“多子类衍生的多继承”问题，Decorator模式的应用要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

　　4．对于Decorator模式在实际中的运用可以很灵活。 如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类可以是ConcreteComponent的一个子类。



图10

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



图11

　　5．Decorator模式的优点是提供了比继承更加灵活的扩展， 通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合。

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

　　适用性

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

　　1.需要扩展一个类的功能，或给一个类增加附加责任。

　　2.需要动态地给一个对象增加功能，这些功能可以再动态地撤销。

　　3.需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。

　　总结

　　Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。
版权所有：UML软件工程组织