设计模式学习笔记（十）Decorator装饰（结构型模式）

 缘起

假如我们需要为游戏中开发一种坦克，除不同型号的坦克外，我们还希望在不同场合中为其增加以下一种或多种功能：比如红外线夜视功能，水陆两栖功能，卫星定位功能……等等。

//抽象坦克
public abstract class Tank{
 public abstract Shot();
 public abstract Run();
}

//各种型号
public class T50:Tank{...}
public class T75:Tank{...}
public class T90:Tank{...}

//各种不同功能的组合
public class T50A:T50,IA{...}
public class T50B:T50,IB{...}
public class T50AB:T50,IA,IB{...}

...随着功能的扩展，子类数量急剧膨胀，子类复子类，子类何其多？

动机（Motivation）

上述问题的根源在于我们过度地使用了继承来扩展对象的功能。由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀（多继承）。

如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题，从而使得任何“功能扩展变化”所导致的影响降为最低？

对强类型语言来说，所谓“静态特质”在这里指在编译时就确定了。一个功能就需要一个类型。动态则指绑定发生在运行时态或者运行时实现。

意图（Intent）

动态地给一个对象增加一些额外的职责，就增加功能而言，Decorator模式比生成子类更为灵活。
　　　　　　　　　　　　——《设计模式》GoF

代码示例：

public abstract class Tank
{
 abstract void Shot();
 abstract void Run();
}

 

public abstract Decorator:Tank //这实际是接口继承，不是类继承，表示在行为上可以作为Tank使用，具体还是通过聚合的实体类来实现的。
{
 private Tank tank;//这里是Has-A对象组合
 
 public Decorator(Tank tank)
 {
  this.tank = tank;
 }
 
 public override void Shot()
 {
  tank.Shot();
 }
 
 public override void Run()
 {
  tank.Run();
 }
}

//装饰类
public class DecoratorA:Decorator
{
 public DecoratorA(Tank tank):base(tank)
 {
 
 }
 public override void Shot()
 {
  //Do some extension 功能扩展...
  
  base.Shot();
 }
 
 public override void Run()
 {
  //do some extension 功能扩展...
  
  base.Run();
 }
}

//装饰类
public class DecoratorB:Decorator
{
 public DecoratorB(Tank tank):base(tank)
 {
 
 }
 public override void Shot()
 {
  //Do some extension 功能扩展...
  
  base.Shot();
 }
 
 public override void Run()
 {
  //do some extension 功能扩展...
  
  base.Run();
 }
}

public class T50:Tank
{
 public override void shot()
 {
  base.Shot();
 }
 
 public override void Run()
 {
  base.Run();
 }
}

 

class App
{
 public static void Main()
 
 {
  Tank tank = new T50();
  Decoratora da = new DecoratorA(tank);
  DecoratorB db = new DecoratorB(da);
  //如此可以一直扩展下去...
  //这样在添加一个功能时只需要添加一个装饰类，实现了动态扩展
 
 }
}

 

Decorator模式的要点

１）通过采用组合而非继承的手法，Decorator实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生”问题。
２）Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明——换言之，Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能。
３）Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一外或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象。
４）Decorator模式并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——这就是“装饰”的含义。装饰是什么？扩展而已。

 

.NET框架中的Decorator模式

以Stream类为例，它实际上是一个抽象类，而FileStream和NetworkStream等是继承自它的实体类。而BufferedStream 和CryptoStream则为装饰类。用法举例如下：

class App
{
 public static void Main()
 {
  MemoryStream ms = new MemoryStream(new byte[]{100,203,456,777,921,345});
  BufferedStream buff = new BufferedStream(ms);//扩展了缓冲功能
  CryptoStream crypto = new CryptoStream(buff);//扩展了缓冲和加密两项功能
  
 }
}