前情提要
上集讲到, 小光利用策略模式搞起了回馈顾客的活动. 还别说, 客流量增大不少.
然而, 随之而来的, 顾客的声音也不少:
- 可乐能不能加冰啊
- 绿豆汤加点糖呗
......
众口难调嘛, 大家的需求不一, 有的要冰有的不要, 有的加糖有的不要... 小光带着客户的意见, 开始了饮品的改进之路.
改进之路
第一套方案
很快, 小光想出了第一套的解决方案: 我把加冰和不加冰的的饮料看成是两种不同的饮料, 借助上次设计的工厂方法模式的饮料机, 可以很轻易的扩展实现用户不同需求, 而不修改原来的实现啊.
小光的第一套方案:
然而, 还没有投入使用呢, 小光就发现了问题:
我这不定期会从饮料商户那儿拿到一些不同的饮品, 每种都有可能要加冰, 加糖, 还可能加蜂蜜呢...那我不用干别的啦, 天天折腾这些饮料机就够够的啦.
装饰出场
那么有什么更好的办法呢? 小光又陷入了冥想.
这时, 表妹过来了, 兴高采烈的, 看到小光傻傻的样子, 问: "表哥, 你想啥呢, 看看我刚新买的头花好看不?"
小光: "你怎么又换头花了啊?"
表妹: "女孩子嘛, 当然要换着花样打扮装饰自己啊, 好不好看嘛?"
"好看好看." 小光敷衍答道.
突然, 小光像是想起了什么, 喃喃自语道, "打扮", "装饰", "对啊, 我也可以用冰啊, 糖啊, 蜂蜜什么的来装饰我的饮料啊."
说做就做, 小光先从可乐入手:
良好的面向接口编程习惯, 小光抽象了一个饮料类Drink
public interface Drink {
String make();
}
实现一杯可乐:
public class Coke implements Drink {
@Override
public String make() {
return "这是一杯可乐";
}
}
加了冰块的饮料还应该是饮料, 故而, 冰块这个装饰也实现了Drink接口, 加冰这个装饰是在饮料的基础上的, 所以我们还持有了一个Drink对象:
public class Ice implements Drink {
private Drink originalDrink;
public Ice(Drink originalDrink) {
this.originalDrink = originalDrink;
}
@Override
public String make() {
return originalDrink.make() + ", 加一块冰";
}
}
来实验下:
public class XiaoGuang {
public static void main(String[] args) {
Drink coke = new Coke();
System.out.println(coke.make());
Drink iceCoke = new Ice(new Coke());
System.out.println(iceCoke.make());
}
}
结果:
这是一杯可乐
这是一杯可乐, 加一块冰
持续改进
小光看到实验结果, 哈哈大笑, 实验成功, 且看我推广到所有饮料, 所有加料中.
小光想到, 加料可能是糖, 可能是冰, 还可能蜂蜜, 还有很多未知的, 为了满足开闭原则, 我还是先抽象一个配料出来吧:
public abstract class Stuff implements Drink {
private Drink originalDrink;
public Stuff(Drink originalDrink) {
this.originalDrink = originalDrink;
}
@Override
public String make() {
return originalDrink.make() + ", 加一份" + stuffName();
}
abstract String stuffName();
}
冰块原料改为继承Stuff:
public class Ice extends Stuff {
public Ice(Drink originalDrink) {
super(originalDrink);
}
@Override
String stuffName() {
return "冰";
}
}
小光还据此增加了糖Sugar, 和蜂蜜Honey原料.
具体代码就不在此贴出来了, 全部代码在这里.
投入使用
经过大量验证后, 小光将新的程序投入了使用, 现在是这样子的...
"老板, 来一杯可乐, 加冰"
Drink iceCoke = new Ice(new Coke());
System.out.println(iceCoke.make());
这是一杯可乐, 加一份冰
"老板, X饮料, 加冰, 加糖"
Drink iceSugarXDrink = new Ice(new Sugar(new XDrink()));
System.out.println(iceSugarXDrink.make());
这是一杯X牌饮料, 加一份糖, 加一份冰
"可乐, 加两份冰, 加蜂蜜"
Drink doubleIceHoneyCoke = new Ice(new Ice(new Honey(new Coke())));
System.out.println(doubleIceHoneyCoke.make());
这是一杯可乐, 加一份蜂蜜, 加一份冰, 加一份冰
完美表现.
小光再也不怕顾客们的各种奇怪的加料要求了.
故事之后
照例, 故事之后, 我们用UML类图来梳理下上述的关系:
其中Stuff类中值得注意的两个关系:
我们的
Stuff(料)也是实现了Drink接口的, 这是为了说明加了料(Stuff)的饮料还是饮料.
Stuff中还聚合了一个Drink(originalDrink)实例, 是为了说明这个料是加到饮料中的.
对, 这个就是一个标准的装饰者模式的类图.
装饰者模式就是用来动态的给对象加上额外的职责.
Drink是被装饰的对象, Stuff作为装饰类, 可以动态地给被装饰对象添加特征, 职责.
扩展阅读一
有的同学可能会说, 我完全可以通过继承关系, 在子类中添加职责的方式给父类以扩展啊. 是的, 没错, 继承本就是为了扩展.
然而, 装饰者模式和子类继承扩展的最大区别在于:
装饰者模式强调的是动态的扩展, 而继承关系是静态的.
由于继承机制的静态性, 我们会为每个扩展职责创建一个子类, 例如IceCoke, DoubleIceCoke, SugarXDrink, IceSugarXDrink等等...会造成类爆炸.
另外, 这里引入一条新的面向对象编程原则:
组合优于继承, 大家自行体会下.
扩展阅读二
还有的同学说, 这种按需定制的方式貌似跟之前讲的Builder模式有点像啊, 那为什么不用Builder模式呢.
这里先说明下二者的本质差异:
Builder模式是一种创建型的设计模式. 旨在解决对象的差异化构建的问题.
装饰者模式是一种结构型的设计模式. 旨在处理对象和类的组合关系.
实际上在这个例子中, 我们是可以用Builder模式的, 但就像使用继承机制一样, 会有些问题.
首先, Builder模式是构建对象, 那么实际上要求我们是必须事先了解有哪些属性/职责供选择. 这样我们才可以在构建对象时选择不同的Build方式. 也就是说:
Builder模式的差异化构建是可预见的, 而装饰者模式实际上提供了一种不可预见的扩展组合关系.
例如, 如果用户要了一杯带蜂蜜的X饮料, 如果是Builder模式, 我们可能是这样的:
XDrink xDrink = new XDrink.Builder()
.withHoney()
.build()
但是如果饮料拿出来后, 用户还想加冰怎么办呢? 这就是Builder模式在这种动态扩展情景下的局限. 看看装饰模式怎么做:
// 加蜂蜜的X饮料
Drink honeyXDrink = new Honey(new XDrink());
System.out.println(honeyXDrink.make());
这是一杯X牌饮料, 加一份蜂蜜
// 还要加冰
Drink iceHoneyXDrink = new Ice(honeyXDrink);
System.out.println(iceHoneyXDrink.make());
这是一杯X牌饮料, 加一份蜂蜜, 加一份冰
直接在honeyXDrink的基础上再装饰一份冰即可.
另外, 大家也都看到了, 由于我们的面向接口编程方式, 装饰者(冰块, 蜂蜜, 糖)可不是只能用来装饰特定的被装饰对象(诸如可乐), 它们可以被用来装饰所有种类的饮料(Drink)对象. 个中好处大家自行体会下.
扩展阅读三
我们一直在说的, 装饰者模式是动态给对象加上额外的职责, 这个职责实际上包括修饰(属性), 也包括行为(方法).
例如我们上面讨论的例子, 就是单纯得给饮料加上了一些修饰, 是饮料编程了加冰的饮料, 加糖的饮料. 我们也可以给对象加上行为, 例如, 一部手机, 我们可以通过装饰模式给它加上红外遥控的功能, 还可以给他加上NFC支付的功能.
Android中鼎鼎大名的Context体系, 实际上就是装饰模式的体现, 通过装饰模式来给Context扩展了一系列的功能. 如下:
还是比较清晰的, 典型的使用装饰者模式来扩展功能的实践, 相比于我们的例子, 更注重功能扩展, 体现了开闭原则.
再重申下, 面向对象编程是一种思想, 设计模式都是这些思想的具体实践和体现. 学习设计模式可以让我们更好的理解编程思想, 而非固定套用. 我们的目的是无招胜有招.
另外, 具体的环境中设计模式一般不是单一地用的, 往往是各种设计模式融合在一起的. 例如我们这个装饰者里面, 各种new对象, 实际上就可以用到我们学习的工厂方法的模式进行处理.
