前情提要

上集讲到, 小光利用策略模式搞起了回馈顾客的活动. 还别说, 客流量增大不少.

然而, 随之而来的, 顾客的声音也不少:

可乐能不能加冰啊
绿豆汤加点糖呗
......

众口难调嘛, 大家的需求不一, 有的要冰有的不要, 有的加糖有的不要... 小光带着客户的意见, 开始了饮品的改进之路.

改进之路

第一套方案

很快, 小光想出了第一套的解决方案: 我把加冰和不加冰的的饮料看成是两种不同的饮料, 借助上次设计的工厂方法模式的饮料机, 可以很轻易的扩展实现用户不同需求, 而不修改原来的实现啊.

小光的第一套方案:

然而, 还没有投入使用呢, 小光就发现了问题:

我这不定期会从饮料商户那儿拿到一些不同的饮品, 每种都有可能要加冰, 加糖, 还可能加蜂蜜呢...那我不用干别的啦, 天天折腾这些饮料机就够够的啦.

装饰出场

那么有什么更好的办法呢? 小光又陷入了冥想.
这时, 表妹过来了, 兴高采烈的, 看到小光傻傻的样子, 问: "表哥, 你想啥呢, 看看我刚新买的头花好看不?"
小光: "你怎么又换头花了啊?"
表妹: "女孩子嘛, 当然要换着花样打扮装饰自己啊, 好不好看嘛?"
"好看好看." 小光敷衍答道.

突然, 小光像是想起了什么, 喃喃自语道, "打扮", "装饰", "对啊, 我也可以用冰啊, 糖啊, 蜂蜜什么的来装饰我的饮料啊."

说做就做, 小光先从可乐入手:

良好的面向接口编程习惯, 小光抽象了一个饮料类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对象, 实际上就可以用到我们学习的工厂方法的模式进行处理.

好了, 让我们充分发挥自己的想象力, 多弄些原料来装饰我们的饮料吧, 说不定我们能调出一种前所未有的饮品呢, 哈哈.

系列文在此: 小光的开店之路--设计模式