设计模式学习之路 - 装饰者模式 - 动态扩展器

今天了解下装饰者模式。

首先，看下需求。

一家咖啡厅需要做一个订单系统，为了配合他们的饮料供应需求。

首先有一个超类，饮料类。

package com.chris.decorator;public abstract class Beverage {String description = "Unkown Beverage";public String getDescription() {return description;}public abstract double cost();}

他有一个属性，对饮料的描述，两个方法，一个方法是返回描述，另一个方法是抽象方法， 返回饮料的价钱。

然后我们开始做事了，创建一个实体类，比如摩卡咖啡，继承饮料类，然后加上相应的描述并且重写cost()方法就行了。

每一种饮料都写一个类去继承，比如蒸馏咖啡， 黑咖啡， 拿铁咖啡等等等等。。

好像看起来没有什么问题。

这时候，其他的需求就来了， 购买咖啡的时候，顾客可以要求向咖啡中加入各种调料， 比如蒸奶， 豆浆， 摩卡 或者奶泡等等。

然后我们开始不同的尝试。

第一种尝试：

按照上面的思路，我们对每一种不同的咖啡都创建一种新的类，去继承超类，然后通过返回不同的描述和价格，达到我们的目的。

比如：黑咖啡， 加蒸奶的黑咖啡，加摩卡的黑咖啡， 加蒸奶和摩卡的黑咖啡。。。。。等等等等。。。

这时候我们会发现一个问题了，通过不同的组合，我们必须要穷举所有的类型，才能把这个系统完善，这就要“类爆炸”了，现实中要维护这么多同种类是十分可怕而且愚蠢的。

由于第一种方案很low，我们开始考虑其他的方案

第二种尝试：

我们通过在超类中加属性，蒸奶，摩卡等等。。然后返回是否需要蒸奶，是否需要摩卡等方法。。

这样的话，通过设置不同的属性，我们可以定义出不同的饮料，只需要设置是否需要蒸奶，是否需要摩卡等字段就行了，再通过调料的选择计算价格。

这个方案好像是比上面理智点，只需要基本的饮料类了， 至少不会由于调料的增加再增加新的类。

但是仔细想想， 好像还是有什么不妥，如果再要加新的调料的话，我们还需要把这个超类属性和相应的方法也修改。

这就违背了设计模式的一个重要的原则：类应该对扩展开发，对修改关闭。

第三种尝试：

这里，我们就开始引入我们的装饰者模式。

为何叫装饰者呢，就是因为我们只需要建一个饮料的对象，就可以用不同的调料去装饰他，而且可以一层一层的装饰，

最后调用cost()方法，通过依赖委托将调料的价格动态的加上去。

如何理解呢，我们直接看代码吧，前面的超类已经有了，我就不重复贴代码了。

这里，我们需要加一个新的装饰者类---调料类，并且继承饮料类，他只有一个抽象方法。

package com.chris.decorator;public abstract class Condiment extends Beverage{public abstract String getDescription();}

我们先实现一种咖啡， 浓缩咖啡！

package com.chris.decorator;public class Espresso extends Beverage{public Espresso() {description = "Espresso";}@Overridepublic double cost() {return 30;}}

然后我们再实现一种具体的调料，摩卡！

package com.chris.decorator;public class Mocha extends Condiment{Beverage beverage;public Mocha(Beverage beverage) {this.beverage = beverage;}@Overridepublic String getDescription() {return beverage.getDescription() + " add Mocha";}@Overridepublic double cost() {return beverage.cost() + 3;}}

调料的实现就比较关键了，在调料中，我们会有一个Beverage的属性，当传入某种饮料后，会预先处理这种饮料的方法，并返回当前饮料的最后价格。

这样的话，就把调料装饰了传入的饮料， 并且可以一层一层的装饰，并且返回最后的价格。

为了测试，我们再加入一种调料，奶泡！

package com.chris.decorator;public class Whip extends Condiment {Beverage beverage;public Whip(Beverage beverage) {this.beverage = beverage;}@Overridepublic String getDescription() {return beverage.getDescription() + " add Whip";}@Overridepublic double cost() {return beverage.cost() + 5;}}

下面，我们要点一杯浓缩咖啡，再点一杯加了摩卡和奶泡的浓缩咖啡！

package com.chris.decorator;public class CoffeeTestDrive {public static void main(String[] args) {Beverage beverage1 = new Espresso();System.out.println(beverage1.getDescription() + " ¥" + beverage1.cost());Beverage beverage2 = new Espresso();beverage2 = new Mocha(beverage2);beverage2 = new Whip(beverage2);System.out.println(beverage2.getDescription() + " ¥" + beverage2.cost());}}

再贴下测试结果咯， 钱应该算的清吧，算数应该没这么差吧。。

Espresso ¥30.0Espresso add Mocha add Whip ¥38.0

有木有很方便，一下让代码变的优雅起来。

这就是装饰者模式：动态的将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

使用装饰者模式, 可以让我们不需要改变原有的代码就可以动态的扩展新的需求.

在JDK的源码中, FilterInputStream 和 BufferedInputStream 就是使用的装饰着模式,通过一层一层的装饰,将inputStream的功能丰富化.