设计模式:装饰模式(Decorator Pattern)
2013-02-28 17:49
776 查看
作者:TerryLee 创建于:2006-03-01 出处:http://terrylee.cnblogs.com/archive/2006/03/01/340592.html 收录于:2013-02-28
![](http://images.cnitblog.com/blog/484791/201302/28174452-0eb8527f269d4ac291957b1e1c3a5d3d.png)
[/b]
需要动态地给一个对象增加功能,这些功能可以再动态地撤销。
需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变得不现实。
![](file:///E:/QMDeDocument/CodeCollection/%E5%9B%BE%E7%89%87%E6%94%B6%E8%97%8F/designpattern/behaviorpattern/d1.gif)
![](file:///E:/QMDeDocument/CodeCollection/%E5%9B%BE%E7%89%87%E6%94%B6%E8%97%8F/designpattern/behaviorpattern/d4.jpg)
![](http://images.cnitblog.com/blog/484791/201302/28174528-2102a78aff864e38a9eb431d01f24d63.jpg)
我们分析一下这样会带来什么好处?
1)首先对于扩展功能已经实现了真正的动态增加,只在需要某种功能的时候才进行包装;
2)其次,如果再出现一种新的扩展功能,只需要增加一个对应的包装子类(注意:这一点任何时候都是避免不了的),而无需再进行很多子类的继承,不会出现子类的膨胀,同时Decorator模式也很好的符合了面向对象设计原则中的“优先使用对象组合而非继承”和“开放-封闭”原则。
2.Decorator类在接口上表现为is-a
Component的继承关系,即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a
Component的组合关系,即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象,且装饰后的对象仍然是一个Component对象。
3.Decortor模式并非解决“多子类衍生的多继承”问题,Decorator模式的应用要点在于解决“主体类在多方向上的扩展功能”——是为“装饰”的含义。
4.对于Decorator模式在实际中的运用可以很灵活。如果只有一个ConcreteComponent类而没有抽象的Component类,那么Decorator类可以是ConcreteComponent的一个子类。如果只有一个ConcreteDecorator类,那么就没有必要建立一个单独的Decorator类,而可以把Decorator和ConcreteDecorator的责任合并成一个类。
5.Decorator模式的优点是提供了比继承更加灵活的扩展,通过使用不同的具体装饰类以及这些装饰类的排列组合,可以创造出很多不同行为的组合。
6.由于使用装饰模式,可以比使用继承关系需要较少数目的类。使用较少的类,当然使设计比较易于进行。但是,在另一方面,使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难,特别是这些对象看上去都很相像。
[b]结构图[/b]
[b]![](http://images.cnitblog.com/blog/484791/201302/28174452-0eb8527f269d4ac291957b1e1c3a5d3d.png)
[/b]
意图
动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。适用性
需要扩展一个类的功能,或给一个类增加附加责任。需要动态地给一个对象增加功能,这些功能可以再动态地撤销。
需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变得不现实。
![](file:///E:/QMDeDocument/CodeCollection/%E5%9B%BE%E7%89%87%E6%94%B6%E8%97%8F/designpattern/behaviorpattern/d1.gif)
实现代码
![](file:///E:/QMDeDocument/CodeCollection/%E5%9B%BE%E7%89%87%E6%94%B6%E8%97%8F/designpattern/behaviorpattern/d4.jpg)
![](http://images.cnitblog.com/blog/484791/201302/28174528-2102a78aff864e38a9eb431d01f24d63.jpg)
using System; public abstract class Log { public abstract void Write(string log); } public class DatabaseLog : Log { public override void Write(string log) { Console.WriteLine("记录到数据库中"); } } public class TextFileLog : Log { public override void Write(string log) { Console.WriteLine("记录到文本文件中"); } } public abstract class LogWrapper : Log //继承,组合 { private Log _log; public LogWrapper(Log log) { _log = log; } public override void Write(string log) { _log.Write(log); } } public class LogErrorWrapper : LogWrapper { public LogErrorWrapper(Log _log): base(_log) { } public override void Write(string log) { SetError(); //......功能扩展 base.Write(log); } public void SetError() { Console.WriteLine("实现了记录错误严重级别"); } } public class LogPriorityWrapper : LogWrapper { public LogPriorityWrapper(Log _log): base(_log) { } public override void Write(string log) { SetPriority(); //......功能扩展 base.Write(log); } public void SetPriority() { Console.WriteLine("实现了记录优先级别"); } } 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"); Console.Read(); } }
我们分析一下这样会带来什么好处?
1)首先对于扩展功能已经实现了真正的动态增加,只在需要某种功能的时候才进行包装;
2)其次,如果再出现一种新的扩展功能,只需要增加一个对应的包装子类(注意:这一点任何时候都是避免不了的),而无需再进行很多子类的继承,不会出现子类的膨胀,同时Decorator模式也很好的符合了面向对象设计原则中的“优先使用对象组合而非继承”和“开放-封闭”原则。
效果及实现要点
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的一个子类。如果只有一个ConcreteDecorator类,那么就没有必要建立一个单独的Decorator类,而可以把Decorator和ConcreteDecorator的责任合并成一个类。
5.Decorator模式的优点是提供了比继承更加灵活的扩展,通过使用不同的具体装饰类以及这些装饰类的排列组合,可以创造出很多不同行为的组合。
6.由于使用装饰模式,可以比使用继承关系需要较少数目的类。使用较少的类,当然使设计比较易于进行。但是,在另一方面,使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难,特别是这些对象看上去都很相像。
相关文章推荐
- 极速理解设计模式系列:23.装饰器模式(Decorator Pattern)
- 24种设计模式--装饰模式【Decorator Pattern】
- 乐在其中设计模式(C#) - 装饰模式(Decorator Pattern)
- 设计模式-装饰模式(Decorator Pattern)
- 设计模式之装饰模式(Decorator Pattern)
- 极速理解设计模式系列:23.装饰器模式(Decorator Pattern)
- 7.5.1.2 装饰设计模式(THE DECORATOR DESIGN PATTERN)
- DOTA版设计模式——装饰模式[Decorator Pattern]
- 乐在其中设计模式(C#) - 装饰模式(Decorator Pattern)
- android设计模式-装饰模式(Decorator Pattern)
- 基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)
- 设计模式拾荒之装饰器模式( Decorator Pattern ): 代理模式的双胞胎兄弟
- "围观"设计模式(13)--结构型之装饰模式(Decorator Pattern)
- 设计模式【装饰模式Decorator Pattern】
- 解读设计模式----装饰模式(Decorator Pattern)
- 设计模式学习笔记十五:装饰模式(Decorator Pattern)
- 二十四种设计模式:装饰模式(Decorator Pattern)
- 设计模式-装饰模式(Decorator Pattern)
- 设计模式_装饰模式(Decorator Pattern)
- 设计模式学习笔记十五:装饰模式(Decorator Pattern)