浅析初窥装饰者模式.doc

初窥装饰者模式赞赞赞场景 考虑这样一种情景：现在，有家咖啡店，他们需要一个设计合理的订单系统。关键需求如下：1.咖啡的种类较多，有爱尔兰（IrishCoffee），星巴克（StarbucksCoffee），雀巢（Nestle）等;2.咖啡中可以添加的配料有糖（Sugar），牛奶（Milk），豆浆（Soy）；3.咖啡的价格还需要包括配料，如果客户点了的话。解决方案 方案一：(下图引用Head First)说明：Beverage为基类，有一个description成员变量来描述饮料，有一个抽象的cost（）方法计算价格。子类较多，例如：爱尔兰牛奶咖啡（IrishCoffeeAndMilk）,爱尔兰双倍牛奶咖啡(IrishCoffeeAndDoubleMilk),and so on。这样的设计简直是类爆炸，在开发的需求阶段，我们不可能确定所有该咖啡店会卖出的咖啡，开发过程中或者开发结束后，他们又发明了新的咖啡种类或者配料种类这样简直就是开发者的噩梦！方案二：（下图引用自Head First）方案一明显是垃圾实现，我们是否可以以“饮料”为主体，用配料来“装饰”之？就像下面：现在顾客点了一杯爱尔兰双倍牛奶咖啡,我们要做的是：1.创建一个爱尔兰咖啡对象2.以牛奶装饰它3.再次用牛奶装饰它4.调用cost方法，并依赖委托将配料的价格算进去例子如下：定义装饰模式 现在我们可以来定义装饰模式了：动态的将行为附加到对象上，若要扩展功能，装饰者提供了优于继承的解决方案。类图如下：代码 1.抽象组建类： public abstract class Beverage String description; public String getDescription() return description; public abstract double cost(); 2.装饰者类（也可以是抽象的，必须继承Beverage，为什么？oh,my God!）public abstract class CondimentDecorator extends Beverage public abstract String getDescription(); 3.爱尔兰咖啡public class IrishCoffee extends Beverage public IrishCoffee() description=爱尔兰咖啡; Override public double cost() return 1.98; 其他咖啡类似，不再给出4.配料（也就是真正的装饰者），以眼泪为例。public class Tear extends CondimentDecorator Beverage beverage; public Tear(Beverage beverage) this.beverage=beverage; Override public String getDescription() return beverage.getDescription()+眼泪; Override public double cost() return 0+beverage.cost(); 终于可以测试了，代码如下：public class Main /* * param args the command line arguments */ public static void main(String args) /一杯加眼泪的爱尔兰咖啡怎么生产？ /1.实例化一杯爱尔兰咖啡 Beverage irish=new IrishCoffee(); /2.用眼泪装饰它 irish=new Tear(irish); System.out.print(irish.getDescription()+irish.cost(); 输出： 这就是装饰模式，它可以动态地将行为添加到对