装饰模式(Decorator)(包装器模式(Wrapper))

 

 

      生活中的装饰是很好理解的,我们打两个比方。先还是说房子的装修,装修无非就是要在墙上刷上粉贴上壁纸挂上饰物,让房屋显得更加雅致美观。但墙还是那堵墙,本质不会改变,只是多了一层包装而已。

 

 

      再看一个例子,假设说你有一个一个的列车车厢,每一个车厢都有对运输功能作一些不同的增强,然后你选取一些这样的车厢,连接起来,形成一个专列,这个专列的功能就是组成它的那些车厢的功能的叠加。这些都是生活中比较典型的装饰模式,那设计模式中的装饰模式,又是怎样的呢?

 

      先搜索下我们尘封的记忆,隐隐约约好像觉得在哪里见过这种设计模式。哪里呢?没错,你想到了!JAVA中IO流的设计就大量运用了装饰模式。看看我们熟悉的代码:

 

BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream("..")));

 

层层包装,增强功能。这就是装饰模式的要旨。我们来看一下装饰模式的定义:

 

装饰模式(Decorator)也叫包装器模式(Wrapper)。GOF在《设计模式》一书中给出的定义为:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。如何理解呢?举个例子:

 

假设我们现在正在开发一个留言板的应用,为了得到用户的留言,我们可以这样做:

1:

2:

3:

 

 

      这个代码是很浅显易懂的。但是后来我们增加了需求,需要我们得到留言板上的内容后能够过滤掉HTML标签和政治敏感的字眼,这时候我们该怎么办呢?

      修改Content类还是扩展Content类?修改Conent类显然不是个好主意,因为我们有些地方可能还需要最原始的留言。那么继承并扩展Content类呢?也不太可行,为什么呢?一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。我们这里主要考虑到第一种情况。大家想想,过滤掉HTML标签和政治敏感的字眼这两个功能有先后顺序问题。不同的顺序我们就要做做不同的类来实现。如果类似这样的功能又增加了几个,排列组合起来是很可怕的。那如何是好呢?你要停下来好好思索一下了。

 

不要急着去解决上面的问题,我们来看看装饰模式的组成,看完之后就明白了!

1)        抽象构件角色(Component):定义一个抽象接口,以规范准备接收附加责任的对象。

2)        具体构件角色(Concrete Component):这是被装饰者,定义一个将要被装饰增加功能的类。

3)        装饰角色(Decorator):持有一个构件对象的实例,并定义了抽象构件定义的接口。

4)        具体装饰角色(Concrete Decorator):负责给构件添加增加的功能。

 

再看一下装饰模式的图解:

 

 

 

 是不是有点启发了呢?呵呵,开始完善我们的代码:

 

 

 

 

 

 

 

 

 

 

  • 5
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值