First we try, then we trust

  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  183 随笔 :: 111 文章 :: 3187 评论 :: 358 引用

一、 装饰(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
  
{
    
getreturn 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();
    
foreachstring 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"2360 );
    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卷:公共语言运行库》,中国电力出版社

 

0
0
(请您对文章做出评价)
« 上一篇:SQL Server Yukon - Top 10 Features
» 下一篇:C#设计模式(12)-Decorator Pattern
posted on 2004-09-26 02:02 吕震宇 阅读(13428) 评论(27)  编辑 收藏 网摘 所属分类: 设计模式

评论

#1楼 2004-09-29 10:30 zj
我觉得《C#设计模式》中对应章节的装饰button例子很好,由于是GUI设计方面的,所以更能体现出装饰的特点。
  回复  引用    

#2楼[楼主] 2004-09-30 09:05 吕震宇      
同意zj的观点。不过GUI设计的代码实在有些太长了,不如Console的简单。所以上面还是选择了使用ConsoleApplication演示装饰模式。
  回复  引用  查看    

#3楼 2004-10-01 14:39 zj
恩,理解
  回复  引用    

#4楼 2005-01-20 10:15 KingofSC
感觉结构跟objectAdapter一样
  回复  引用    

#5楼 2005-05-27 10:59 gwb
@kingofSC

还是不一样的吧,objectAdapter是为了接口兼容这个方面考虑的,为了一个目标接口而进行的,Decorator感觉就是继承的另一种更灵活的方式

  回复  引用    

#6楼 2005-06-21 14:34 路人
路过
  回复  引用    

decorator

自己的理解,就是一种用相关对象来构造一个新对象的方法。

  回复  引用    

#8楼 2005-10-24 15:24 Daivd[未注册用户]
不理解,装饰方式比继承方式好在哪?
  回复  引用    

#9楼 2005-11-02 15:54 阿k[未注册用户]
模式看得多了在应用场合上有些迷糊。
最好有这样的一种例子:只要变换这个需求便使用不同的模式来实现,
如此在同一个例子上对比一番,为何使用这样或那样的模式,会比较容易理清吧。

不过,应该很难想出这样的例子,或者根本不存在这样的例子,呵

  回复  引用    

#10楼 2005-12-21 16:30 路过[未注册用户]
为什么很多类都用抽象类不用接口表示呢?
  回复  引用    

吕,我发现你一个不好的习惯,总是喜欢ArrayList borrowers = new ArrayList();
个人觉得,IList borrowers = new ArrayList(); 比较好。


还有个很经典的例子:
Stream bs = new BufferedStream (new FileStream(...));

这再java和csharp中都有,是decorator很好的例子。


  回复  引用    

#12楼 2006-04-24 22:55 凉面[未注册用户]
请问我如何可以把例子放在这上面,如果大家有不同的例子放上来供大家参考,可能大家更容易理解这种模式的好处!
  回复  引用    

对于装饰模式,Decorator中维持的Component对象的指针所指向的对象是否应该在Decorator中销毁?我觉得这样不妥,毕竟,Decorator给予该Component对象的东西应该是可以动态的增加和删除的,因此,如果对应的Decorator销毁后,Component还应该是那个Component。
  回复  引用    

#14楼 2007-05-13 16:51 助燃      
看明白了,调用的过程有点像递归。不过请问动态的销毁要怎么做呢?
  回复  引用  查看    

#15楼 2007-05-26 11:27 Ray Zhang
@助燃
是new了很多。
如果是Java、C#等有GC的语言,GC会根据generation按代自动销毁,不用管。如果是C++等没有GC的语言也没关系,反正指针已经一条线传进去了所以析构一次就可以了。

  回复  引用    

#16楼 2007-05-26 11:57 助燃      
@Ray Zhang
我的意思是,比如某个对象通过装饰已经拥有了三种功能,我要去掉其中一种怎么办?是重头构造过么?

  回复  引用  查看    

#17楼 2007-07-19 15:52 炭炭      
re: C#设计模式(12)-Decorator Pattern 2005-10-24 15:24 Daivd
不理解,装饰方式比继承方式好在哪? 回复 更多评论
——————————————————

注意装饰模式可以在各个平行类之间自由组合,当然它们都集成统一接口。
如果使用继承完成的话,显然这种组合的自由度没有了,你会得到非常多的具体类,或者非常多的继承层次。

  回复  引用  查看    

#18楼 2007-07-19 15:54 炭炭      
LZ 第2个图书馆的例子我觉得举的例子不是很好,按照他自己的说法就是 半透明的装饰模式,不是纯粹的装饰模式。

  回复  引用  查看    

#19楼 2007-08-04 19:41 Allan[未注册用户]
@qiucx0161
经测试
Stream bs = new BufferedStream (new FileStream(...));
应该为:
BufferedStream bs = new BufferedStream (new FileStream(...));

  回复  引用    

#20楼 2007-08-04 19:48 Allan[未注册用户]
我觉得,Decorator对一个基类下面的所有子类对象进行了包装,用的时候只需要将这些子类注入到Decorator中就可以使用了,而如果用继承的话,这些子类都要重复写相同的代码,就会造成代码冗余,并且修改的时候不灵活,要对每个子类继承的方法进行修改,用Decorator的话就非常方便
  回复  引用    

#21楼 2007-08-04 19:57 Allan[未注册用户]
看了TerryLee的Decorator才发现自己理解错了...
http://terrylee.cnblogs.com/archive/2006/03/01/340592.html
使用继承方法会违反单一职责原则,多重继承......,子类冗余,楼上的 炭炭 说的好

  回复  引用    

#22楼 2008-05-10 15:24 Dare[未注册用户]
恩............
装饰模式是不是可以理解成为
以继承树的广度为代价来减小继承树的深度呢?

  回复  引用    

#23楼 2008-06-13 01:38 Bēniaǒ      
Decorator模式--给喜欢使用继承的人一个全新的世界
优先使用对象组合而非继承”和“开放-封闭”原则都体现出了。

  回复  引用  查看    

#24楼 2008-11-22 15:43 vevi[未注册用户]
个人感觉这一章写的不是很好。
恩,博主只是说了装饰着模式的广度:孙悟空可以变成鸟,可以变成鱼。。。
但是装饰者模式在深度上也可以应用,比如head first一书中的例子,咖啡可以加糖,还可以再加摩卡以及牛奶等等,最后得出这一杯咖啡的价钱。
希望博主将这篇文章完善,给学习者一个清楚的认知。
例外 图书馆的例子不太好,是不是应该换一个呢。

  回复  引用