第三个模式：装饰者模式
3.1 模式引入
辛巴克咖啡，购买咖啡时，也可以要求在其中加入各种调料，例如：蒸奶（Steamed milk）、豆浆（soy）、摩卡（Mocha）或者覆盖奶泡。星巴克会根据所加入的调料收取不同的费用。所以订单系统必须考虑到这些调料部分。
3.2 解决方案1：
采用继承来实现方案：
这种方案的特点：
1.一旦出现新调料，我们将需要加上新的方法，并改变超类中的cost()方法；
2.以后开发新的饮料，对这些新饮料而言，某些调料可能并不合适，但是在这个设计方式中，Tea(茶)子类依然继承那些不合适的方法
3.万一客户需要双倍摩卡，怎么办？？
设计原则：类应该对扩展开放，对修改关闭
如上所示我们已经知道继承无法完全解决我们想要的问题，容易出现：类数量爆炸、设计死板、以及基类加入的新功能并不适用所有的子类。
3.2 解决方案2：
我们考虑引入新的方法：我们要以饮料为主体，然后在运行时以调料来“装饰”饮料。比方说，如果顾客想要摩卡和奶泡深赔咖啡，那么，要做的是：
我们由此可以知道：
由此引入装饰者模型：
装饰者模型：动态地将责任附加到对象上，若要扩张功能，装饰者提供了比继承更有弹性的替代方案。
如下图是装饰者模型的类图：
下面是星巴克的框架：
装饰者模型的重点在于：装饰者和被装饰者必须是一致的类型，也就是拥有共同的超类，这是相当关键的地方。在这里我们利用继承达到了“类型匹配”，而不是利用继承获得“行为”。
具体的实现可以见源代码，o(∩_∩)o 。
下面是片段：
3.4装饰者模型的应用：JAVA I/O
下图是JAVA I/O的类图架构：
