设计模式——装饰者模式

本文是阅读 Head First 设计模式——装饰者模式的总结。 这本书的教学模式很不错，我的很喜欢，由实际的案例由浅入深，按部就班的让你明白良好的设计是多么的优雅迷人（回头看看本身的代码，WTF！）。 可是读第二遍的时候，竟然想不起来这章节说了什么，到底怎么解决这个问题的。也就是说，看的时候爽快，看完了并无应用到具体的Coding中。

这一章节的案例是：设计星巴兹咖啡系统

相关的背景：
星巴兹咖啡如今有四种咖啡：黑咖啡(HouseBlend)、深度烘焙咖啡(DarkRoast)、脱咖啡因咖啡(Decaf)、浓咖啡(Espresso)。
用户在购买咖啡时，能够要求在其中加入各类调料，例如：蒸奶（Steamed Milk）、豆浆（Soy）、摩卡（Mocha）或覆盖奶泡（Whip）。会根据所加入的调料收取不一样的费用，因此订单系统必须考虑到这些调料的价格。

原先的类设计

若是按照这种模式，在某种咖啡中加入调料，那么就是一个新的子类，继承 Beverage ，实现本身的 cost() 方法，算出咖啡以及调料的价格。以此类推，这是一个类爆炸的系统，有多少种花样就要为此设计多少类。

很明显，星巴兹为本身制做了一个维护噩梦。若是牛奶涨价了，怎么办？新增一种焦糖风味调料时，怎么办？

很明显，这种设计是有致命的缺陷的。

优化方案

利用实例变量和继承，能够追踪调料，不必去设计这么多类。

这样设计有哪些缺陷呢？

• 调料价格变化时，须要更改现有代码
• 出现新的调料，须要添加新的方法，并改动超类中的cost()方法
• 之后开发新的饮料，对于这些饮料，某些调料并不适合，可是这个设计中，子类仍需继承那些不须要的方法
• 万一顾客想要双倍摩卡怎么办？

固然这种设计，违反了基本的开闭原则，类应该对扩展开放，对修改关闭。

装饰者模式

从上面的方案来看，咱们利用继承没法彻底解决问题，如今遇到的问题有：类数量爆炸、设计死板，以及基类加入的新功能并不适用全部的子类。

因此，在这里要采用不同的作法：以饮料为主体，而后再运行时以调料来“装饰”（decorate）饮料。好比，若是顾客想要摩卡和奶泡深焙咖啡,那么，要作的是：

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

上面是pdf文本的截图，这个过程若是不画出来，就漏掉了很重要的按部就班的过程。

装饰者模式：动态的将责任附加到对象上。如果要扩展功能，装饰者提供了比继承更有弹性的替代方案。

上图是装饰者模式的结构类图。

废话很少说，看看咱们的订单系统该如何写。

原始的类图中，超类Beverage基本不用改动。

public abstract class Beverage {
    String description = "";

    public String getDescription() {
        return description;
    }

    public abstract double cost();
}
复制代码

下面实现调料类的抽象类，也就是装饰者类：

// 为了让CondimentDecorator 可以取代 Beverage，全部才继承Beverage
public abstract class CondimentDecorator extends Beverage {
    public abstract String getDescription();
}
复制代码

下面是饮料实体类，按照上面的包装图例，咱们就实现DarkRoast就行了。

public class DarkRoast extends Beverage {

    public DarkRoast() {
        description = "DarkRoast";
    }

    @Override
    public double cost() {
        return 1.99;
    }
}
复制代码

下面是Mocha 和 Whip 的调料代码

public class Mocha extends CondimentDecorator {
    Beverage beverage;

    public Mocha(Beverage beverage) {
        this.beverage = beverage;
    }

    public String getDescription() {
        return beverage.getDescription() + ", Mocha";
    }

    public double cost() {
        return 0.20 + beverage.cost();
    }
}
复制代码

public class Whip extends CondimentDecorator {
    Beverage beverage;

    public Whip(Beverage beverage) {
        this.beverage = beverage;
    }

    public String getDescription() {
        return beverage.getDescription() + ", Whip";
    }

    public double cost() {
        return 0.10 + beverage.cost();
    }
}
复制代码

好了，依照装饰者模式，咱们完成了基本的代码实现。下面是测试代码：

public class StarbuzzCoffee {
    public static void main(String[] args) {
        // 一杯DarkRoast，不须要调料
        Beverage beverage = new DarkRoast();
        System.out.println(beverage.getDescription() + " $" + beverage.cost());

        // 一杯DarkRoast，加双份Mocha和奶泡
        Beverage beverage2 = new DarkRoast();
        beverage2 = new Mocha(beverage2);
        beverage2 = new Mocha(beverage2);
        beverage2 = new Whip(beverage2);
        System.out.println(beverage2.getDescription() + " $" + beverage2.cost());
    }
}
复制代码

运行结果以下：

DarkRoast $1.99
DarkRoast, Mocha, Mocha, Whip $2.49

Process finished with exit code 0
复制代码

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

文章原本是打算简单的总结下该章节的内容，方便之后资料的查找，回忆下知道大概讲的是什么东西，写下来发现，若是不可以将这个按部就班的过程写下来，那么就失去这本书基本的宗旨。 上面的内容基本都是章节的文本，主要是担忧本身理解误导了读者。

若是对文章的内容感兴趣，不妨去读一下《Head First设计模式》。