第3章 装饰者模式
1、定义/说明
动态、透明的将职责附加到对象上（或从对象上撤销），而不影响其他对象。若要扩展功能，装饰者模式提供了比继承更富有弹性的替代方案。
2、介绍
首先让我们先来介绍一下场景，EDI_KAI咖啡店开业了，需要有一套咖啡订单系统，以合乎他们的饮料供应需求。
注意：购买咖啡时，根据客户需要可以在其中加入各种调料，例如，蒸奶(Steamed Milk)，豆浆(Soy)，摩卡(Mocha也就是巧克力风味)或者覆盖奶泡
下面是我们的初步设计方案：
为了设计的健壮性，所以订单系统必须考虑到调料部分，我们的第一个尝试如下：
每个cost()方法将计算出咖啡加上订单上调料的价钱
发现设计上有什么问题了吗？这种近似“类爆炸”的设计，后期的维护简直就是噩梦。
如果我们使用装饰者模式来设计呢？会是什么样子呢？就让我们来看一下吧。
在这个需求中，总的来说，饮料（也就是咖啡）在确定之后是不会发生变更的，而调料就不一样了，不同的客户在选中同一种饮料之后可能会选择不同的调料，这时候我们就需要拿调料来为饮料调味（也就是我们说的用调料来装饰饮料），所以，我们以饮料为主题，然后在运行时以调料来装饰饮料,调料要继承或实现饮料主题。比方说顾客想要摩卡和奶泡深焙咖啡，我们要做的就是：
1）、拿一个深焙咖啡（DarkRoast）对象
2）、以摩卡（Mocha）对象装饰它
3）、以奶泡（Whip）对象装饰它
4）、调用cost()方法，并依赖委托(delegate)将调料的加钱加上去
来看一下我们通过装饰者模式设计之后的类图：
解释下这个类图，其中Beverage(饮料)是一个抽象类或者接口（也就是我们说的主题/或者组件）；HouseBlend、DarkRoast、Espresso、Decaf作为具体的饮料（也就是被装饰者）继承自/实现Beverage超类；而CondimentDecorator作为装饰者基类也需要继承/实现Beverage超类，只有这样我们才能在运行时让装饰者去装饰被装饰者，以打到修改被装饰者的目的；Milk、Mocha、Soy、Whip作为具体的装饰者需要继承CondimentDecorator基类。
顺便说一下，JDK中的I/O就是采用的装饰者模式，如果以前的童鞋对这块不是很明白，在学习了装饰者模式后，估计很快就会明白了
本章要点：
Ж 定义：动态、透明的将职责附加到对象上（或从对象上撤销），而不影响其他对象。若要扩展功能，装饰者模式提供了比继承更富有弹性的替代方案
Ж 应用场景：
Ж 新设计原则：面向修改关闭，面向扩展开放
Ж 要慎用装饰者模式，除非必须，过度使用装饰者模式，小对象过多，会使程序变得非常复杂。
关于第3章 装饰者模式模式就介绍到这里，如果以上内容有出错的地方，还请不吝赐教；如果大家觉得有讲的不明白地方，也可提出来，大家共同学习。
第4章的工厂模式会在最近几天更新....
谢谢阅读
转载请表明出处。
