装饰模式(Decorator Pattern)
2013-03-17 10:48
411 查看
生活中的装饰是很好理解的,我们打两个比方。先还是说房子的装修(我不是故意的),装修无非就是要在墙上刷上粉贴上壁纸挂上饰物,让房屋显得更加雅致美观。但墙还是那堵墙,本质不会改变,只是多了一层包装而已。再看一个例子,假设说你有一个一个的列车车厢,每一个车厢都有对运输功能作一些不同的增强,然后你选取一些这样的车厢,连接起来,形成一个专列,这个专列的功能就是组成它的那些车厢的功能的叠加。这些都是生活中比较典型的装饰模式,那设计模式中的装饰模式,又是怎样的呢?
先搜索下我们尘封的记忆,隐隐约约好像觉得在哪里见过这种设计模式。哪里呢?没错,你想到了!JAVA中IO流的设计就大量运用了装饰模式。看看我们熟悉的代码:
BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream("..")));
层层包装,增强功能。这就是装饰模式的要旨。我们来看一下装饰模式的定义:
装饰模式(Decorator)也叫包装器模式(Wrapper)。GOF在《设计模式》一书中给出的定义为:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。
(1) 装饰对象和真实对象有相同的接口。这样客户端对象就可以和真实对象相同的方式和装饰对象交互。
(2) 装饰对象包含一个真实对象的引用(reference)
(3) 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象。
(4) 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时,不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中,通常是通过继承来实现对给定类的功能扩展。
如何理解呢?举个例子:
假设我们现在正在开发一个留言板的应用,为了得到用户的留言,我们可以这样做:
这个代码是很浅显易懂的。但是后来我们增加了需求,需要我们得到留言板上的内容后能够过滤掉HTML标签和政治敏感的字眼,这时候我们该怎么办呢?修改Content类还是扩展Content类?修改Conent类显然不是个好主意,因为我们有些地方可能还需要最原始的留言。那么继承并扩展Content类呢?也不太可行,为什么呢?一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。我们这里主要考虑到第一种情况。大家想想,过滤掉HTML标签和政治敏感的字眼这两个功能有先后顺序问题。不同的顺序我们就要做做不同的类来实现。如果类似这样的功能又增加了几个,排列组合起来是很可怕的。那如何是好呢?你要停下来好好思索一下了。
先不要急着去解决上面的问题,我们来看看装饰模式的组成,看完之后就明白了!
1) 抽象构件角色(Component):定义一个抽象接口,以规范准备接收附加责任的对象。
2) 具体构件角色(Concrete Component):这是被装饰者,定义一个将要被装饰增加功能的类。
3) 装饰角色(Decorator):持有一个构件对象的实例,并定义了抽象构件定义的接口。
4) 具体装饰角色(Concrete Decorator):负责给构件添加增加的功能。
再看一下装饰模式的图解:
是不是有点启发了呢?呵呵,开始完善我们的代码:
怎么样,把这个例子跑出来后,你体会到装饰模式的妙处了吗?好好的思考一下上面的图和代码,我想,你一定会恍然大悟的。
先搜索下我们尘封的记忆,隐隐约约好像觉得在哪里见过这种设计模式。哪里呢?没错,你想到了!JAVA中IO流的设计就大量运用了装饰模式。看看我们熟悉的代码:
BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream("..")));
层层包装,增强功能。这就是装饰模式的要旨。我们来看一下装饰模式的定义:
装饰模式(Decorator)也叫包装器模式(Wrapper)。GOF在《设计模式》一书中给出的定义为:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。
(1) 装饰对象和真实对象有相同的接口。这样客户端对象就可以和真实对象相同的方式和装饰对象交互。
(2) 装饰对象包含一个真实对象的引用(reference)
(3) 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象。
(4) 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时,不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中,通常是通过继承来实现对给定类的功能扩展。
如何理解呢?举个例子:
假设我们现在正在开发一个留言板的应用,为了得到用户的留言,我们可以这样做:
package com.softeem.decorator; /** * @author leno 用户留言板处理的接口 */ public interface MessageBoardHandler { public String filter(String msg); } package com.softeem.decorator; /** * @author leno 用户留言板的具体实现 */ public class MessageBoard implements MessageBoardHandler { public String filter(String msg) { return "处理留言板上的内容:" + msg; } } package com.softeem.decorator; /** * @author leno 客户端测试 */ public class Test { public static void main(String[] args) { MessageBoardHandler mb = new MessageBoard(); String content = mb.filter("一定要学好装饰模式!"); System.out.println(content); } }
这个代码是很浅显易懂的。但是后来我们增加了需求,需要我们得到留言板上的内容后能够过滤掉HTML标签和政治敏感的字眼,这时候我们该怎么办呢?修改Content类还是扩展Content类?修改Conent类显然不是个好主意,因为我们有些地方可能还需要最原始的留言。那么继承并扩展Content类呢?也不太可行,为什么呢?一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。我们这里主要考虑到第一种情况。大家想想,过滤掉HTML标签和政治敏感的字眼这两个功能有先后顺序问题。不同的顺序我们就要做做不同的类来实现。如果类似这样的功能又增加了几个,排列组合起来是很可怕的。那如何是好呢?你要停下来好好思索一下了。
先不要急着去解决上面的问题,我们来看看装饰模式的组成,看完之后就明白了!
1) 抽象构件角色(Component):定义一个抽象接口,以规范准备接收附加责任的对象。
2) 具体构件角色(Concrete Component):这是被装饰者,定义一个将要被装饰增加功能的类。
3) 装饰角色(Decorator):持有一个构件对象的实例,并定义了抽象构件定义的接口。
4) 具体装饰角色(Concrete Decorator):负责给构件添加增加的功能。
再看一下装饰模式的图解:
是不是有点启发了呢?呵呵,开始完善我们的代码:
package com.softeem.decorator; /** * @author leno 装饰角色 */ public class MessageBoardDecorator implements MessageBoardHandler { private MessageBoardHandler handler; public MessageBoardDecorator(MessageBoardHandler handler) { super(); this.handler = handler; } public String filter(String msg) { return handler.filter(msg); } } package com.softeem.decorator; /** * @author leno 具体装饰角色,增加过滤掉HTML标签的功能 */ public class HtmlFilter extends MessageBoardDecorator { public HtmlFilter(MessageBoardHandler handler) { super(handler); } public String filter(String content) { String temp = super.filter(content); temp += "^^过滤掉HTML标签!^^"; return temp; } } package com.softeem.decorator; /** * @author leno 具体装饰角色,增加过滤掉政治敏感字眼的功能 */ public class SensitiveFilter extends MessageBoardDecorator { public SensitiveFilter(MessageBoardHandler handler) { super(handler); } public String filter(String content) { String temp = super.filter(content); temp += "^^过滤掉政治敏感的字眼!^^"; return temp; } } package com.softeem.decorator; /** * @author leno 客户端测试 */ public class Test { public static void main(String[] args) { MessageBoardHandler mb = new MessageBoard(); String content = mb.filter("一定要学好装饰模式!"); System.out.println(content); mb = new HtmlFilter(new SensitiveFilter(new MessageBoard())); content = mb.filter("一定要学好装饰模式!"); System.out.println(content); } }
怎么样,把这个例子跑出来后,你体会到装饰模式的妙处了吗?好好的思考一下上面的图和代码,我想,你一定会恍然大悟的。
相关文章推荐
- 装饰模式例子(Decorator Pattern)
- 设计模式学习笔记十五:装饰模式(Decorator Pattern)
- 装饰模式【Decorator Pattern】
- 装饰模式(Decorator Pattern)
- Java之装饰模式(Decorator Pattern)
- 设计模式[6] Decorator Pattern 装饰模式
- 装饰模式(Decorator Pattern)
- Java设计模式十九:装饰模式(Decorator Pattern)
- 设计模式_装饰模式(Decorator Pattern)
- 结构型模式之装饰模式(Decorator Pattern)C++实现
- (第Ⅲ部分 结构型模式篇) 第9章 装饰模式(Decorator Pattern)
- 装饰模式(Decorator Pattern、Wrapper Pattern,对象结构型模式)
- 设计模式拾荒之装饰器模式( Decorator Pattern ): 代理模式的双胞胎兄弟
- 对上层架构和游戏底层的看法|Decorator Pattern |装饰器模式
- 装饰模式(Decorator Pattern)
- 设计模式(十二)-装饰器模式(Decorator Pattern)——装饰边框与被饰物的一致性
- 面向对象设计模式之---装饰模式(Decorator Pattern)
- 我读设计模式之装饰模式(Decorator Pattern)
- 装饰设计模式 Learn Decorator Design Pattern in Easy Steps
- 极速理解设计模式系列:23.装饰器模式(Decorator Pattern)