浅析初窥装饰者模式.pdfVIP

初窥装饰者模式

场景

考虑这样一种情景：现在,有家咖啡店,他们需要一个设计合理的订单系统。关键需求如下：

1.咖啡的种类较多,有爱尔兰（IrishCoffee）,星巴克（StarbucksCoffee）,

雀巢（Nestle）等;

2.咖啡中可以添加的配料有糖（Sugar）,牛奶（Milk）,豆浆（Soy）；

3.咖啡的价格还需要包括配料,如果客户点了的话。

解决方案

方案一：(下列图引用HeadFirst)

1/6

说明：Beverage为基类,有一个description成员变量来描述饮料,有一个抽象的cost（）

方法计算价格。子类较多,例如：爱尔兰牛奶咖啡（IrishCoffeeAndMilk）,爱尔兰双倍牛奶

咖啡(IrishCoffeeAndDoubleMilk),andsoon。这样的设计简直是类爆炸,在开发的需求阶

段,我们不可能确定所有该咖啡店会卖出的咖啡,开发过程中或者开发结束后,他们又创造了

新的咖啡种类或者配料种类——这样简直就是开发者的噩梦！

方案二：（下列图引用自HeadFirst）

方案一明显是垃圾实现,我们是否可以以“饮料〞为主体,用配料来“装饰〞之？

就像下面：

现在顾客点了一杯爱尔兰双倍牛奶咖啡,我们要做的是：

1.创立一个爱尔兰咖啡对象

2.以牛奶装饰它

3.再次用牛奶装饰它

4.调用cost方法,并依赖委托将配料的价格算进去

2/6

例子如下：

定义装饰模式

现在我们可以来定义装饰模式了：

动态的将行为附加到对象上,若要扩展功能,装饰者提供了优于继承的解决方案。

类图如下：

3/6

代码

1.抽象组建类：

publicabstractclassBeverage{

Stringdescription;

publicStringgetDescription(){

returndescription;

}

publicabstractdoublecost();

}

2.装饰者类（也可以是抽象的,必须继承Beverage,为什么？oh,myGod!）

publicabstractclassCondimentDecoratorextendsBeverage{

publicabstractStringgetDescription();

}

3.爱尔兰咖啡

publicclassIrishCoffeeextendsBeverage{

4/6

publicIrishCoffee(){

description=爱尔兰咖啡;

}

@Override

publicdoublecost(){

return1.98;

}

}

其他咖啡类似,不再给出

4.配料（也就是真正的装饰者）,以眼泪为例。

publicclassTearextendsCondimentDecorator{

Beveragebeverage;

publicTear(Beveragebeverage){

this.beverage=beverage;

}

@Override

publicStringgetDescription(){

returnbeverage.getDescription()++眼泪;

}

@Override