星巴克咖啡订单项目（咖啡馆）:

1) 咖啡种类/单品咖啡：Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)

2) 调料：Milk、Soy(豆浆)、Chocolate

3) 要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便

4) 使用OO的来计算不同种类咖啡的费用: 客户可以点单品咖啡，也可以单品咖啡+调料组合。

 

方案1——根据各种组合情况建立类

问题：这样设计，会有很多类，当我们增加一个单品咖啡，或者一个新的调料，类的数量就会倍增，就会出现类爆炸。

 

面临的问题很类似于桥接，但是不同于桥接，咖啡是一开始就存在了，不是桥接完具体品牌之后才能使用，咖啡知识要加牛奶或者豆浆，本身不依赖于桥接后的对象。

 

方案2——将配料设为内置属性，通过判断确定是否添加

解决了类爆炸问题，但是如果要添加或删除调料时，代码维护量很大。

 

方案3——采用装饰者模式

1，装饰者模式定义

1) 装饰者模式：动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(ocp)

2) 这里提到的动态的将新功能附加到对象和ocp原则，在后面的应用实例上会以代码的形式体现，请同学们注意体会。

 

也就是说装饰者模式的核心在于添加新功能。

 

2，装饰者模式原理

1) 装饰者模式就像打包一个快递

主体：比如：陶瓷、衣服 (Component) // 被装饰者

包装：比如：报纸填充、塑料泡沫、纸板、木板(Decorator)

2) Component

主体：比如类似前面的Drink

3) ConcreteComponent和Decorator

ConcreteComponent：具体的主体，比如前面的各个单品咖啡

Decorator: 装饰者，比如各调料.

4) 在如图的Component与ConcreteComponent之间，如果

ConcreteComponent类很多,还可以设计一个缓冲层，将共有的部分提取出来，抽象层一个类。

3，用装饰者模式设计的方案

这里的核心在于Decorator类：
public class Decorator extends Drink {
    private Drink obj;
    
    public Decorator(Drink obj) { //组合
        // TODO Auto-generated constructor stub
        this.obj = obj;
    }....

每一个Decorator都包着一个Drink对象，而它的核心处理方法，一层一层处理。Decorator中的计算价格方法：
    @Override
    public float cost() {
        // TODO Auto-generated method stub
        // getPrice 自己价格
        return super.getPrice() + obj.cost();
    }
因此装饰者模式通过包裹的一个对象，多做一些处理，达到添加附加功能。

装饰者模式下的订单：2份巧克力+一份牛奶的LongBlack

说明：
1) Milk包含了LongBlack
2) 一份Chocolate包含了(Milk+LongBlack)
3) 一份Chocolate包含了(Chocolate+Milk+LongBlack)
4) 这样不管是什么形式的单品咖啡+调料组合，通过递归方式可以方便的组合和维护。
 

4，装饰者模式在JDK应用的源码分析

Java的IO结构，FilterInputStream就是一个装饰者

public abstract class InputStream implements Closeable{} //是一个抽象类，即Component
public class FilterInputStream extends InputStream { //是一个装饰者类Decorator
protected volatile InputStream in //被装饰的对象 }
class DataInputStream extends FilterInputStream implements DataInput { //FilterInputStream 子类，

比如在FilterInputStream ：
class FilterInputStream extends InputStream {

    protected volatile InputStream in;

    public int read() throws IOException {
        return in.read();
    }
...

也就是每一层装饰，在外层可以加一些处理实现新的功能。