天天看点

[Java基础] 设计模式之装饰者模式写在前面

CSDN话题挑战赛第2期

参赛话题:学习笔记

写在前面

作者简介:鲸海鹿林

博客主页:鲸海鹿林的主页

名言警句:keep calm and carry on

本系列参照HeadFirst系列设计模式

这本书,换言之,是 HeadFirst设计模式这本书的读书笔记,让我们一起学习吧! 

 装饰者模式(Decorate Pattern)

装饰者模式——给爱用继承的人一个全新的设计眼界

星巴兹的故事

[Java基础] 设计模式之装饰者模式写在前面
[Java基础] 设计模式之装饰者模式写在前面

很明显,星巴兹为自己制作了一个维护噩梦——如果牛奶的价钱上扬,这么办?新增一种焦糖调料风味时,怎么办?造成这种维护噩梦的,违反了我们之前谈到的那种设计原则?

思考

如果不设计那么多的类,反而使用实例变量和继承,是否可以?

我们先试试看,从Beverage基类下手,加上实例变量代表是否加上调料(牛奶、豆浆、摩卡、奶泡……),类图如下:

[Java基础] 设计模式之装饰者模式写在前面
[Java基础] 设计模式之装饰者模式写在前面

现在,一共只需要5个类,但这真的是我们想要的吗?思考一下未来可能需要的变化,想一想这种做法是否存在着一些潜在的问题。

[Java基础] 设计模式之装饰者模式写在前面

下面让我们看一下设计原则中非常重要的一个原则——开闭原则

[Java基础] 设计模式之装饰者模式写在前面

我们的目标是允许类容易扩展,在不修改现有代码的情况下,就可搭配新的行为。这样的设计具有弹性,可以应对改变,可以接受新的功能来应对改变的需求。

[Java基础] 设计模式之装饰者模式写在前面

虽然似乎有点矛盾,但是确实有一些技术可以允许在不直接修改代码的情况下对其进行扩展。在选择需要被扩展的代码部分时要小心。每个地方都采用开闭原则也是一种浪费,还会导致代码变得复杂且难以理解。

认识装饰者模式

好了,我们已经认识到,利用继承无法完全解决问题,在星巴兹遇到的问题有:类数量爆炸、设计死板,以及基类加入的新功能并不适用于所有的子类。因此,我们要采取不同的做法:以饮料为主体,然后再运行时以调料来装饰(decorate)饮料。例如,如果顾客想要摩卡和奶泡深焙咖啡,要做的是:

  1. 拿一个深焙咖啡(DarkRoast)对象
  2. 以摩卡对象(Mocha)对象装饰它
  3. 以奶泡(Whip)对象装饰它
  4. 调用cost()方法,并依赖委托(delegate)将调料的价格加上去

 但是如何“装饰”一个对象,而“委托”有要如何与此搭配使用呢?给个暗示:把装饰者对象当成“包装者”。下面让我们看看这是如何工作的……

[Java基础] 设计模式之装饰者模式写在前面
[Java基础] 设计模式之装饰者模式写在前面

 好了,这是目前所知道的一切:

  • 装饰者和被装饰对象有相同的超类型
  • 你可以使用一个或者多个装饰者去包装一个对象
  • 既然装饰者和被装饰的对象有着相同的超类型,所以在任何需要原始对象(被包装的)的场合,可以用装饰过的对象代替它
  • 装饰者可以在所委托被装饰者的行为之前与/或之后,加上自己的行为,以带到特定的目的。
  •  对象可以在任何时候被装饰,所以可以在运行是动态地、不限量地用你喜欢的装饰者来装饰对象

 装饰者模式的定义

[Java基础] 设计模式之装饰者模式写在前面

 装饰我们的饮料

[Java基础] 设计模式之装饰者模式写在前面

办公室隔间的对话

[Java基础] 设计模式之装饰者模式写在前面

代码实现

先从Beverage类下手,这不需要改变星巴兹原始的设计:

[Java基础] 设计模式之装饰者模式写在前面

 Beverage很简单,让我们来实现Condiment(调料)抽象类,也就是装饰者类:

[Java基础] 设计模式之装饰者模式写在前面

写饮料的代码

[Java基础] 设计模式之装饰者模式写在前面

 写调料的代码

[Java基础] 设计模式之装饰者模式写在前面

供应咖啡

[Java基础] 设计模式之装饰者模式写在前面

问题与解答

[Java基础] 设计模式之装饰者模式写在前面

真实世界的装饰者:Java I/O

[Java基础] 设计模式之装饰者模式写在前面

装饰java.io类

[Java基础] 设计模式之装饰者模式写在前面
[Java基础] 设计模式之装饰者模式写在前面

模式访谈

[Java基础] 设计模式之装饰者模式写在前面