Head First 设计模式总结(三) 装饰者模式

本文对装饰者模式进行了概括和总结

装饰者模式

动态的将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
一旦你熟悉了装饰的技巧，你将能够在不修改任何代码的前提下，给你的(或别人的)对象赋予新的职责。

问题描述

有一家名为“星巴兹咖啡”的咖啡店，随着饮品种类的增加，他们的订单系统需要更新。现在有四种咖啡种类：HouseBlend、DarkRoast、Decaf、Espresso，还有四种调料：Milk、Soy、Mocha、Whip，每种咖啡都可以搭配这四种调料中的一种或者多种。

有一个滥用继承的人这样做：他将所有情况都用一个具体的类弄出来，并让每一个类都去继承Beverage(饮料)这个顶层类。这样的话，就算每种咖啡只搭配一种调料的话，就已经有16种咖啡品种了，这相当的复杂。当其中一种调料(比如牛奶)的价格变化时，就要去所有用到了牛奶的饮品类中去做相应修改，维护成本特别高。

现在用装饰者模式解决这个问题

做法：

以饮料为主体，在运行时用调料去装饰饮料，比方说，顾客需要摩卡和奶泡深焙咖啡，需要做的是：
1、弄一个深焙咖啡对象(DarkRoast)
2、用摩卡(Mocha)对象装饰它
3、用奶泡(Whip)对象装饰它
4、调用cost()方法和getDescription()方法，通过委托将调料的价格全部累加到饮料的价格上，得到总价和最后的饮料名称。
下图是采用装饰者模式应该用的框架：

抽象类Beverage为顶层类，CondimentDecorator类为装饰者类的顶层类，所有装饰者都继承于它，为了装饰Beverage，抽象类CondimentDecorator也必须继承Beverage。

下面是实现代码：
先给出Beverage类的代码

public abstract class Beverage {
    String description;
    public String getDescription(){
        return description;
    }
    public abstract double cost();
}

其中一种咖啡DarkRoast的实现如下

public class DarkRoast extends Beverage {
    DarkRoast(){
        description = "DarkRoast coffee";
    }
    @Override
    public double cost() {
        return 0.99;   //价格为0.99
    }
}

再给出CondimentDecorator类的代码

/*
*由于CondimentDecorator类继承了Beverage，只需加上额外的方法或者成员
*/
public abstract class CondimentDecorator extends Beverage {
    public abstract String getDescription();  //加入调料的话，咖啡的名称会被调料修饰
}

下面给出两种调料(Mocha和Whip)的代码
Mocha的代码

public class Mocha extends CondimentDecorator {
    Beverage beverage;  //利用组合将待装饰的Beverage对象进行装饰
    Mocha(Beverage beverage){
        this.beverage = beverage;   //将待装饰的beverage对象通过构造器传进来，以对其信息进行装饰
    }
    @Override
    public double cost() {
        return beverage.cost() + 0.20;//经过Mocha装饰后，饮料的总价在原来的基础上又增加了0.2
    }
    @Override
    public String getDescription() {
        return beverage.getDescription() + " + Mocha"; //经过Mocha装饰后，饮料的描述也加上了Mocha
    }
}

Whip的代码

public class Whip extends CondimentDecorator {
    Beverage beverage;

    Whip(Beverage beverage){
        this.beverage = beverage;
    }
    @Override
    public double cost() {
        return beverage.cost() + 0.10;//Whip额外加收0.1
    }
    @Override
    public String getDescription() {
        return beverage.getDescription() + " + Whip";
    }
}

现在已经有了一种咖啡和两种调料，可以先测试一下装饰者

用咖啡店的名字作为测试用的主类，测试代码如下：

public class StarBuzzCoffee {
    public static void main(String [] args){
        Beverage beverage = new DarkRoast();//只有咖啡的饮料
        System.out.println("当前饮料为："+beverage.getDescription()+"  价格为："+beverage.cost());
        beverage = new Mocha(beverage);//在咖啡的基础上加入Mocha
        System.out.println("当前饮料为："+beverage.getDescription()+"  价格为："+beverage.cost());
        beverage = new Whip(beverage);//在之前的基础上加上Whip
        System.out.println("当前饮料为："+beverage.getDescription()+"  价格为："+beverage.cost());
    }
}

得到的结果为：

当前饮料为：DarkRoast coffee  价格为：0.99
当前饮料为：DarkRoast coffee + Mocha  价格为：1.19
当前饮料为：DarkRoast coffee + Mocha + Whip  价格为：1.29

[注]

上述的beverage = new Mocha(beverage)之所以成立，是因为Mocha等调料也继承自Beverage，这个语句相当于进行了向下转型，Beverage是顶层组件，下面的子类都是用来装饰它的，尽管执行这句话之后beverage引用的对象类型就变成了Mocha，但是Mocha继承自Beverage，这个beverage还是Beverage，不用去在意这些细节，因为“beverage”这个名字一开始就给他了，不管今后有多少个装饰者装饰它，它永远叫"beverage"，并不是很影响可读性。

总结

这节提出了一个设计原则(开闭原则)：对扩展开放，对修改关闭。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

装饰者也会使设计中出现许多小对象，不能过度使用，否则会让程序变得非常复杂。