文章内容参考<Head First设计模式>
我们用书中的例子为例，一步步了解装饰者模式
一家咖啡店因为扩张速度变快，准备更新订单系统，以符合他们的饮品供应需求
其中包括一个超类Beverage ：
并且包含了它的两个派生类 DarkRoast和HouseBlend，其中cost方法返回了该咖啡的价格
购买咖啡时候，也可以在其中加入各种调料，例如：豆浆（Soy），摩卡（Mocha）,咖啡店会根据所加入的调料收取不同的费用，所以订单系统必须考虑到这些调料部分
Joe很荣幸又被分配到了找个任务！
Joe第一次尝试，每种咖啡搭配一个口味时候都选择新建一个类来维护，那么出现了一下的场景
哇哦，好多的类，这简直是维护的噩梦，维护上造成了很大的困难
Joe提出了它的第二个建议，从Beverage类下手，加入实例变量代表是否加入调料
乍一看好像还不错，但是又会发生以下的问题，
1.每次有新配料的时候都要在Beverage里添加新的方法，久而久之庞大而臃肿
2.某些饮品可能跟这里的大部分配料不合适比如（茶），这样的会造成很大的代码冗余
3.顾客想要双倍或者更深层次的搭配呢？
此时，Joe面临最重要的设计原则之一：类应该对扩展开放，对修改关闭
我们的目标允许类容易扩展，在不修改现有代码的情况下，就可以搭配新的行为
那么什么是装饰者模式呢？
我们以一杯双层摩卡+豆浆咖啡（DrakRoast）为例
首先我们将咖啡（DrakRoast）作为一个对象
用摩卡对象来装饰它
用豆浆对象来装饰它
我们从DrakRoast对象开始
想要摩卡，我们在摩卡类内包含咖啡对象获得摩卡咖啡对象
想要豆浆，我们在豆浆类内包含摩卡咖啡对象获得摩卡豆浆咖啡对象
通过最外层的豆浆装饰者的cost就可以得到最终的价格
我们看一下装饰者模式的类图
看不懂或者感觉花没关系，后面我们用代码来一步步解析
我们通过 一杯双倍摩卡豆浆咖啡 来进行一步步实现装饰者模式
文章头部我们已经创建了两个咖啡类型DrakRoast与HouseBlend，接下来
我们创建一个（调料）Condiment抽象类来继承超类，并且我们要求派生类必须重写getDescription方法
创建两个调料的派生类豆浆(Soy)和摩卡(Mocha)类
我们通过构造传递了超类型的数据，并且通过重写cost方法和get..方法改变了产品描述、
效果很nice 我们可以选择动态的给咖啡添加各种装饰了，回头在去看一遍类图是不是会更深刻一点呢
现在的咖啡具有很强的扩展弹性，假设咖啡店新加入了大，中，小杯的设定，我们进行一下拓展
我们考虑到大中小的设定需要铺设在所有的前面，因为不同规格的咖啡配料价格都不一样
首先在Beverage类中添加相关变量方法
以Soy为代表 处理尺寸问题和计算价格问题
大杯的豆浆咖啡结果
装饰者模式：动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案
169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
