基本需求：
- 咖啡的种类有很多种，调料也有很多种，下单时，可以点单品咖啡也可以点单品咖啡+调料的组合，并计算下单时花费的金额
传统方式：
- 方式一
- 创建一个抽象类Drink，让所有的单品咖啡和组合咖啡都继承Drink类(组合很多)
- UML类图
- 如果新增加一个单品咖啡或者调料，类的数量就会倍增，产生类爆炸
- 方式二
- 创建一个抽象类Drink，在Drink类中将所有的调料聚合进去，再让我们的单品咖啡继承Drink类
- UML类图
- 此种方式解决了类爆炸的问题，但是新增或者删除调料时，需要修改Drink类中的内容，违反了ocp原则
基本介绍：
动态的将新功能加到对象上，不改变其结构，属于结构型模式
UML类图（原理图）
装饰者模式就像打包一个快递
- 主体为打包的东西（Component）-> 被装饰者
- 包装的东西（Decorator）-> 装饰者
- Drink为主体（Component）
- 单品咖啡为具体的主体（ConcreteComponent）
- 调料为装饰者（Decorator）
- 如果ConcreteComponent类很多，还可以向上抽取一个缓冲层
- 让装饰者和具体的主体继承同一类可以对同一个具体的主体，进行多次包装，通过递归的方式
- 如果ConcreteComponent和Decorator不是继承同一类，则用递归不容易,Decorator不仅需要维护自身还需维护ConcreteComponent的变量（不一定行），继承同一个抽象类，只需要在Decorator中维护一个抽象父类即可
- 例如：点两个chocolate和一个milk + Espresso咖啡，示例
UML类图（案例）
代码实现
如果再增加单品咖啡或者调料时，只需继承Coffee或者Decorator类即可，系统的扩展性提高了，解决了类爆炸，体现了ocp原则，动态的为被装饰的类添加功能
jdk源码：
在jdk的io源码中就使用到的装饰者模式
UMl类图
InputStream作为抽象父类，相当于Drink类
FileInputStream、StringBufferInputStream、ByteArrayInputStream继承了InputStream相当于咖啡单品（并没有再进行抽象），被装饰者
FilterInputStream继承了InputSteam并且内部维护了一个其父类InputStream相当于一个Decorator装饰者
BufferInputStream、DataInputStream、LineNumberInputStream继承了FilterInputStream，相当于Milk、ChocolateD等，为装饰者的子类
关键代码
注意事项：
- 装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能，多层装饰比较复杂
- 扩展一个类的功能，动态增加功能，动态撤销