装饰者模式(Decorator Pattern)

最新推荐文章于 2023-05-04 21:03:59 发布
最新推荐文章于 2023-05-04 21:03:59 发布
阅读量1.7k 收藏
点赞数
分类专栏： 设计模式

设计模式 - 吕震宇

.NET设计模式系列文章

薛敬明的专栏

乐在其中设计模式(C#)


C#设计模式（12）－Decorator Pattern

一、 装饰（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卷：公共语言运行库》，中国电力出版社

 

.NET设计模式（10）：装饰模式（Decorator Pattern）

装饰模式（Decorator Pattern）

——.NET设计模式系列之十

Terrylee，2006年3月

概述

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

意图

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

结构图

图1 Decorator模式结构图

生活中的例子

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

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

装饰模式解说

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

图3

实现代码如下：

public abstractclassLog

{

    public abstract void Write(string log);

}

public classDatabaseLog :Log

{

    public override void Write(string log)

    {

        //......记录到数据库中

    }

}

public classTextFileLog :Log

{

    public override void Write(string log)

    {

        //......记录到文本文件中

    }

}

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

图4

实现代码如下：

public interfaceIError

{

    void SetError();

}

public interfaceIPriority

{

    void SetPriority();

}

public classDBErrorLog :DatabaseLog,IError

{

    public override void Write(string log)

    {

        base.Write(log);

    }

    public void SetError()

    {

       //......功能扩展，实现了记录错误严重级别

    }

}

public classDBPriorityLog :DatabaseLog,IPriority

{

    public override void Write(string log)

    {

        base.Write(log);

    }

    public void SetPriority()

    {

        //......功能扩展，实现了记录优先级别

    }

}

public classTFErrorLog :TextFileLog,IError

{

    public override void Write(string log)

    {

        base.Write(log);

    }

    public void SetError()

    {

        //......功能扩展，实现了记录错误严重级别

    }

}

public classTFPriorityLog :TextFileLog,IPriority

{

    public override void Write(string log)

    {

        base.Write(log);

    }

    public void SetPriority()

    {

        //......功能扩展，实现了记录优先级别

    }

}

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

图5

实现代码：

public classDBEPLog :DatabaseLog,IError,IPriority

{

    public override void Write(string log)

    {

        SetError();

        SetPriority();

        base.Write(log);

    }

    public void SetError()

    {

        //......功能扩展，实现了记录错误严重级别

    }

    public void SetPriority()

    {

        //......功能扩展，实现了记录优先级别

    }

}

public classTFEPLog :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 abstractclassLogWrapper :Log

{

    private Log _log;

    public LogWrapper(Log log)

    {

        _log = log;

    }

    public override void Write(string log)

    {

        _log.Write(log);

    }

}

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

图7

实现代码如下：

public classLogErrorWrapper :LogWrapper

{

    public LogErrorWrapper(Log _log)

        :base(_log)

    {

       

    }

    public override void Write(string log)

    {

        SetError(); //......功能扩展

 

        base.Write(log);

    }

    public void SetError()

    {

        //......实现了记录错误严重级别

    }

}

public classLogPriorityWrapper :LogWrapper

{

    public LogPriorityWrapper(Log _log)

        : base(_log)

    {

 

    }

    public override void Write(string log)

    {

        SetPriority(); //......功能扩展

 

        base.Write(log);

    }

    public void SetPriority()

    {

        //......实现了记录优先级别

    }

}

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

public classProgram

{

    public static void Main(string[] args)

    {

        Log log = new DatabaseLog();

        LogWrapper lew1 = new LogErrorWrapper(log);

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

        lew1.Write("Log Message");

 

        LogPriorityWrapper lpw1 =newLogPriorityWrapper(log);

        //扩展了记录优先级别

        lpw1.Write("Log Message");

 

        LogWrapper lew2 = new LogErrorWrapper(log);

        LogPriorityWrapper lpw2 =newLogPriorityWrapper(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 sealedclassBufferedStream : 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 abstractclassDBCommandWrapper :MarshalByRefObject,IDisposable

{

 

}

public classSqlCommandWrapper :DBCommandWrapper

{

   

}

public classOracleCommandWrapper :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模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。

参考资料

阎宏，《Java与模式》，电子工业出版社

James W. Cooper，《C#设计模式》，电子工业出版社

Alan Shalloway James R. Trott，《Design Patterns Explained》，中国电力出版社

MSDN WebCast 《C#面向对象设计模式纵横谈(10) Decorator装饰模式(结构型模式)》

作者： TerryLee
出处： http://terrylee.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

测试输出

using System;
using System.Collections.Generic;
using System.Text;

namespace DecoratorPatternTest
{
    // Component
    public abstract class Log
    {
        public Log()
        {
            Console.WriteLine("[Log]:Constructor.");
        }

        public abstract void WriteLog(string log);
    }

    //Concrete component
    public class DatabaseLog : Log
    {
        public DatabaseLog()
        {
            Console.WriteLine("[DatabaseLog]:Constructor.");
        }

        public override void WriteLog(string log)
        {
            Console.WriteLine("[DatabaseLog]:" + log);
        } 
    }

    //Concrete component
    public class TextLog : Log
    {
        public TextLog()
        {
            Console.WriteLine("[TextLog]:Constructor.");
        }

        public override void WriteLog(string log)
        {
            Console.WriteLine("[TextLog]:" + log);
        }
    }

    //Decorator
    public abstract class LogWrapper : Log
    {
        private Log _log;

        public LogWrapper(Log log)
        {
            this._log = log;

            Console.WriteLine("[LogWrapper]:Constructor.");
        }

        public override void WriteLog(string log)
        {
            Console.WriteLine("[LogWrapper]:" + log);           //9,此行屏蔽
            this._log.WriteLog(log);
        }
    }

    //Concrete Decorator
    public class LogErrorWrapper : LogWrapper
    {
        public LogErrorWrapper(Log log)
            : base(log)
        {
            Console.WriteLine("[LogErrorWrapper]:Constructor.");
        }

        public override void WriteLog(string log)
        {
            Console.WriteLine("[LogErrorWrapper.Error]:" + log);
            base.WriteLog(log);
        }
    }

    //Concrete Decorator
    public class LogPriorityWrapper:LogWrapper
    {
        public LogPriorityWrapper(Log log)
            : base(log)
        {
            Console.WriteLine("[LogPriorityWrapper]:Constructor."); 
        }

        public override void WriteLog(string log)
        {
            Console.WriteLine("[LogPriorityWrapper.Priority]:" + log); 
            base.WriteLog(log);
        }
    }
    
    class Program
    {
        static void Main(string[] args)
        {
            Log log = new DatabaseLog();                                            //1
            LogWrapper lew1 = new LogErrorWrapper(log);                             //2
            lew1.WriteLog("Log Message Error.");                                    //3

            LogPriorityWrapper lpw1 = new LogPriorityWrapper(log);                  //4
            lpw1.WriteLog("Log Message Priority.");                                 //5

            LogWrapper lew2 = new LogErrorWrapper(log);                             //6
            LogPriorityWrapper lpw2 = new LogPriorityWrapper(lew2);                 //7
            lpw2.WriteLog("Log Message Error and Priority.");                       //8

            Console.Read();
        }
    }
}

输出情况:(每行对应的输出情况)



//9,屏蔽下的输出,(红线部分,通过装饰,扩展后的新功能)


乐在其中设计模式(C#) - 装饰模式(Decorator Pattern)

乐在其中设计模式(C#) - 装饰模式(Decorator Pattern)


作者： webabcd


介绍
动态地给一个对象添加一些额外的职责。就扩展功能而言，它比生成子类方式更为灵活。


示例
有一个Message实体类，某个对象对它的操作有Insert()和Get()方法，现在扩展这个对象的功能。



MessageModel
using  System;
 using  System.Collections.Generic;
 using  System.Text;

 namespace  Pattern.Decorator
 {
    /// <summary>
    /// Message实体类
    /// </summary>
    public class MessageModel
    {
        /// <summary>
        /// 构造函数
        /// </summary>
        /// <param name="msg">Message内容</param>
        /// <param name="pt">Message发布时间</param>
        public MessageModel(string msg, DateTime pt)
        {
            this._message = msg;
            this._publishTime = pt;
        }

        private string _message;
        /// <summary>
        /// Message内容
        /// </summary>
        public string Message
        {
            get { return _message; }
            set { _message = value; }
        }

        private DateTime _publishTime;
        /// <summary>
        /// Message发布时间
        /// </summary>
        public DateTime PublishTime
        {
            get { return _publishTime; }
            set { _publishTime = value; }
        }
    }
}

AbstractMessage
using  System;
 using  System.Collections.Generic;
 using  System.Text;

 namespace  Pattern.Decorator
 {
    /// <summary>
    /// 操作Message的抽象构件（Component）
    /// </summary>
    public abstract class AbstractMessage
    {
        /// <summary>
        /// 获取Message
        /// </summary>
        /// <returns></returns>
        public abstract List<MessageModel> Get();

        /// <summary>
        /// 插入Message
        /// </summary>
        /// <param name="mm">Message实体对象</param>
        /// <returns></returns>
        public abstract bool Insert(MessageModel mm);
    }
}

SqlMessage
using  System;
 using  System.Collections.Generic;
 using  System.Text;

 namespace  Pattern.Decorator
 {
    /// <summary>
    /// Sql方式操作Message（ConcreteComponent）
    /// </summary>
    public class SqlMessage : AbstractMessage
    {
        /// <summary>
        /// 获取Message
        /// </summary>
        /// <returns></returns>
        public override List<MessageModel> Get()
        {
            List<MessageModel> l = new List<MessageModel>();
            l.Add(new MessageModel("SQL方式获取Message", DateTime.Now));

            return l;
        }

        /// <summary>
        /// 插入Message
        /// </summary>
        /// <param name="mm">Message实体对象</param>
        /// <returns></returns>
        public override bool Insert(MessageModel mm)
        {
            // 代码略
            return true;
        }
    }
}

XmlMessage
using  System;
 using  System.Collections.Generic;
 using  System.Text;

 namespace  Pattern.Decorator
 {
    /// <summary>
    /// Xml方式操作Message（ConcreteComponent）
    /// </summary>
    public class XmlMessage : AbstractMessage
    {
        /// <summary>
        /// 获取Message
        /// </summary>
        /// <returns></returns>
        public override List<MessageModel> Get()
        {
            List<MessageModel> l = new List<MessageModel>();
            l.Add(new MessageModel("XML方式获取Message", DateTime.Now));

            return l;
        }

        /// <summary>
        /// 插入Message
        /// </summary>
        /// <param name="mm">Message实体对象</param>
        /// <returns></returns>
        public override bool Insert(MessageModel mm)
        {
            // 代码略
            return true;
        }
    }
}

AbstractMessageWrapper
using  System;
 using  System.Collections.Generic;
 using  System.Text;

 namespace  Pattern.Decorator
 {
    /// <summary>
    /// 装饰AbstractMessage（Decorator）
    /// </summary>
    public abstract class AbstractMessageWrapper : AbstractMessage
    {
        private AbstractMessage _abstractMessage;

        /// <summary>
        /// 构造函数
        /// </summary>
        /// <param name="abstractMessage">AbstractMessage</param>
        public AbstractMessageWrapper(AbstractMessage abstractMessage)
        {
            this._abstractMessage = abstractMessage;
        }

        /// <summary>
        /// 获取Message
        /// </summary>
        /// <returns></returns>
        public override List<MessageModel> Get()
        {
            return _abstractMessage.Get();
        }

        /// <summary>
        /// 插入Message
        /// </summary>
        /// <param name="mm">Message实体对象</param>
        /// <returns></returns>
        public override bool Insert(MessageModel mm)
        {
            return _abstractMessage.Insert(mm);
        }
    }
}

CheckUserWrapper
using  System;
 using  System.Collections.Generic;
 using  System.Text;

 namespace  Pattern.Decorator
 {
    /// <summary>
    /// 扩展出用户验证的功能（ConcreteDecorator）
    /// </summary>
    public class CheckUserWrapper : AbstractMessageWrapper
    {
        /// <summary>
        /// 构造函数
        /// </summary>
        /// <param name="abstractMessage">AbstractMessage</param>
        public CheckUserWrapper(AbstractMessage abstractMessage)
            : base(abstractMessage)
        {
            
        }

        /// <summary>
        /// 获取Message
        /// </summary>
        /// <returns></returns>
        public override List<MessageModel> Get()
        {
            List<MessageModel> l = base.Get();

            foreach (MessageModel mm in l)
            {
                mm.Message += "（经过用户验证）";
            }

            return l;
        }

        /// <summary>
        /// 插入Message
        /// </summary>
        /// <param name="mm">Message实体对象</param>
        /// <returns></returns>
        public override bool Insert(MessageModel mm)
        {
            // 在这里扩展功能

            return base.Insert(mm);
        }

    }
}

CheckInputWrapper
using  System;
 using  System.Collections.Generic;
 using  System.Text;

 namespace  Pattern.Decorator
 {
    /// <summary>
    /// 扩展出输入验证的功能（ConcreteDecorator）
    /// </summary>
    public class CheckInputWrapper : AbstractMessageWrapper
    {
        /// <summary>
        /// 构造函数
        /// </summary>
        /// <param name="abstractMessage">AbstractMessage</param>
        public CheckInputWrapper(AbstractMessage abstractMessage)
            : base(abstractMessage)
        {
            
        }

        /// <summary>
        /// 获取Message
        /// </summary>
        /// <returns></returns>
        public override List<MessageModel> Get()
        {
            List<MessageModel> l = base.Get();

            foreach (MessageModel mm in l)
            {
                mm.Message += "（经过输入验证）";
            }

            return l;
        }

        /// <summary>
        /// 插入Message
        /// </summary>
        /// <param name="mm">Message实体对象</param>
        /// <returns></returns>
        public override bool Insert(MessageModel mm)
        {
            // 在这里扩展功能

            return base.Insert(mm);
        }
    }
}


Test
using  System;
 using  System.Data;
 using  System.Configuration;
 using  System.Collections;
 using  System.Web;
 using  System.Web.Security;
 using  System.Web.UI;
 using  System.Web.UI.WebControls;
 using  System.Web.UI.WebControls.WebParts;
 using  System.Web.UI.HtmlControls;

 using  Pattern.Decorator;

 public  partial  class  Decorator : System.Web.UI.Page
 {
    protected void Page_Load(object sender, EventArgs e)
    {
        AbstractMessage message = new SqlMessage();

        AbstractMessageWrapper amr = new CheckUserWrapper(message);

        Response.Write(amr.Get()[0].Message + " " + amr.Get()[0].PublishTime.ToString());
        Response.Write("<br />");

        AbstractMessageWrapper amr2 = new CheckInputWrapper(message);

        Response.Write(amr2.Get()[0].Message + " " + amr2.Get()[0].PublishTime.ToString());
        Response.Write("<br />");

        AbstractMessageWrapper amr3 = new CheckUserWrapper(message);
        AbstractMessageWrapper amr4 = new CheckInputWrapper(amr3);

        Response.Write(amr4.Get()[0].Message + " " + amr4.Get()[0].PublishTime.ToString());
        Response.Write("<br />");
    }
}

运行结果
SQL方式获取Message（经过用户验证） 2007-5-13 19:34:01
SQL方式获取Message（经过输入验证） 2007-5-13 19:34:01
SQL方式获取Message（经过用户验证）（经过输入验证） 2007-5-13 19:34:01


参考
http://www.dofactory.com/Patterns/PatternDecorator.aspx


OK
[源码下载]

jiangxinyu
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
装饰者模式（Decorator Pattern）原理图
04-10
装饰者模式（Decorator Pattern）是一种结构型设计模式，它的定义是在不改变原有对象结构的基础上，动态地给该对象增加一些职责（即增加其额外功能）。这种模式允许向一个现有的对象添加新的功能，同时又不改变其...
装饰器设计模式
baidu_36775904的博客
04-11 487
装饰器模式（Decorator Pattern）是一种结构型设计模式，用于在不修改原有对象的基础上动态地给对象添加新的功能。装饰器模式通过创建一个新的装饰器类，继承原有类的基本功能，然后扩展或覆盖原有功能。装饰器模式可以在运行时根据需要灵活地给对象添加或组合功能。
设计模式之装饰器模式详解
热门推荐
weixin_45538589的博客
11-19 1万+
设计模式之装饰器模式详解 文章目录设计模式之装饰器模式详解一、什么是装饰者模式二、门面模式的角色组成四、门面模式示例五、门面模式优缺点 一、什么是装饰者模式 装饰器模式（Decorator Pattern） 也称为包装模式(Wrapper Pattern) 是指在不改变原有对象的基础之上，将功能附加到对象上，提供了比继承更有弹性的替代方案(扩展原有对象的功能)，属于结构型模式。装饰器模式的核心是功能扩展，使用装饰器模式可以透明且动态地扩展类的功能。 二、门面模式的角色组成 外观角色（Facade）：
设计模式---装饰器(Decorator)模式
honor_zhang的博客
09-07 1691
1 定义 装饰器（Decorator）模式，也称为包装（Wrapper）模式，是继承关系的一种替代方案。指在不改变对象结构的情况下，动态的给对象添加一些功能。 2 优缺点 2.1 优点 装饰器是继承的有力补充，比继承灵活，在不改变原有对象的情况下，动态的给一个对象扩展功能，即插即用 通过使用不用装饰类及这些装饰类的排列组合，可以实现不同效果 装饰器模式完全遵守开闭原则 2.2 缺点 装饰器模式会增加许多子类，过度使用会增加程序得复杂性。 3 装饰器模式的结构与实现 装饰器模式的类图如下所示：
设计模式之装饰器模式
weixin_64366370的博客
05-04 2423
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。
java 装饰模式（Decorator Pattern）详解
09-01
主要介绍了java 装饰模式（Decorator Pattern）详解的相关资料,需要的朋友可以参考下
详解java装饰模式（Decorator Pattern）
09-02
主要为大家详细介绍了java装饰模式Decorator Pattern，这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装，对装饰器模式感兴趣的小伙伴们可以参考一下
java实现装饰器模式（Decorator Pattern）
08-26
主要为大家详细介绍了java实现装饰器模式Decorator Pattern，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
C#装饰器模式(Decorator Pattern)实例教程
09-04
主要介绍了C#装饰器模式(Decorator Pattern),以一个完整实例形式讲述了C#装饰器模式的实现过程,有助于深入理解C#程序设计思想,需要的朋友可以参考下
学习笔记：设计模式-装饰器设计模式（JAVA）
dingyi4815313的专栏
10-31 401
设计模式-装饰器设计模式（JAVA）
【每天一个java设计模式（九）】 - 装饰器模式
1+1=王的博客
12-22 4214
装饰器模式允许向一个现有的对象添加新的功能，同时又不改变其结构。装饰器模式属于结构型模式，它是作为现有的类的一个包装。 使用给手机添加不同的功能为例，来实现装饰器模式： 装饰器模式的实现 1. 创建一个产品接口 //产品接口 public interface Product { public void function(); //产品的功能 } 2. 创建一个手机类实现产品接口 //手机实体 public class Phone implements Product { publi
学习设计模式之装饰器模式
南淮北安的博客
04-30 278
文章目录一、定义二、问题背景三、违背设计模式的设计实现1. 工程结构2. 代码实现3. 测试验证四、问题改进1. 工程结构2. 代码实现3. 测试验证五、总结 一、定义 初看上图感觉装饰器模式有点像俄罗斯套娃、某众汽车🚕，而装饰器的核心就是再不改原有类的基础上给类新增功能 不改变原有类，可能有的小伙伴会想到继承、AOP切面，当然这些方式都可以实现，但是使用装饰器模式会是另外一种思路更为灵活，可以避免继承导致的子类过多，也可以避免AOP带来的复杂性 你熟悉的场景很多用到装饰器模式 new BufferedR
【设计模式】装饰器模式
✈ 正在努力 の 寒江（StudiousTiger) ✌ 呐 ✈
04-07 5934
什么是装饰器模式 装饰器模式从字面意思来说就是对某一个事物进行装饰的一种模式。从代码层面而言，是对类的一个扩展或者是修饰，从传统方法而言，我们可以使用继承来对某一个类进行扩展，但是往往会导致会出现非常多的子类，如果我们要想避免这种情况，那么我们就可以使用设计模式中的——装饰器模式。 装饰器模式的优缺点 装饰器模式是在不改变现有对象结构的情况下，动态地给该对象增加一些职责，即增加其额外功能。 但是如果对于一个类型装饰的类的扩展功能太多，那么将会导致有很多的小类，我们在选择使用装饰器设计模式的时候要根据实际情况
.NET设计模式-装饰模式（Decorator Pattern）
-云在青天水在瓶
05-23 647
装饰模式（Decorator Pattern）图9概述在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为
设计模式-结构型模式（装饰器模式）
Munger6的博客
05-27 285
装饰器模式的应用场景 含义：创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。 特征：1、可以透明动态的扩展一个类的功能或给一个类添加附加职责； 2、动态的给一个对象添加功能，这些功能可以再动态的撤销； 使用场景：扩展一个类功能； 动态增加功能，动态撤销； 当存在较多复杂的类功能组合的时候，为避免类爆炸，就会采用装饰器模式； 命名规则：Decorator 生活中案例： 咖啡：...
设计模式之装饰器模式（装饰设计模式）
码小春的博客
12-08 439
前言 上班族大多都有睡懒觉的习惯，每天早上上班时间都很紧张，于是很多人为了多睡一会，就会用方便的方式解决早餐问题。有些人早餐可能会吃煎饼，煎饼中可以加鸡蛋，也可以加香肠，但是不管怎么“加码”，都还是一个煎饼。在现实生活中，常常需要对现有产品增加新的功能或美化其外观，如房子装修、相片加相框等，都是装饰器模式。 在软件开发过程中，有时想用一些现存的组件。这些组件可能只是完成了一些核心功能。但在不改变其结构的情况下，可以动态地扩展其功能。所有这些都可以釆用装饰器模式来实现。 装饰器模式的定义与特点 装饰
decorator pattern
最新发布
06-11
装饰器模式（Decorator Pattern）是一种结构型设计模式，它允许您在运行时通过将对象包装在一个装饰器类的对象中来动态地修改对象的行为。使用装饰器模式，您可以将一个对象的行为分成多个单独的类，每个类都可以独立地进行修改，而不会影响其他类的行为。这种模式对于需要动态地添加或删除功能的情况非常有用，因为您可以通过简单地添加或删除装饰器类来实现这些功能，而无需修改原始对象。同时，装饰器模式也遵循了开放/关闭原则（Open/Closed Principle），即对于扩展开放，对于修改关闭。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值