设计模式--装饰者模式

 

星巴克咖啡订单项目（咖啡馆）：

1. 咖啡种类/单品咖啡：Espresso（意大利浓咖啡）、ShortBlack、LongBlack（美式咖啡）、Decaf（无因咖啡）。
2. 调料：milk、Soy（豆浆）、Chocolate。
3. 要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便。
4. 使用OO来计算不同种类咖啡的费用，客户可以点单品咖啡，也可以单品咖啡+调料的组合。

常见的解决方案：

但是这种方案会存在典型的类爆炸问题！

解决星巴克订单问题分析：

1）Drink是一个抽象类或者接口，表示饮料。

2）Desc是对咖啡的描述，表示是拿铁还是Decaf。

3）Cost表示计算费用，Drink类做成一个接口或者抽象方法。

4）Decaf单品咖啡。继承Drink并且实现cost方法。

5）Express&Drink就是单品+调料，这样的组合会有很多。

6）问题是这样设计会有很多类，当我们增加一个单品咖啡或者调料时，类的数量就会倍增，就会出现类爆炸。

方案一会造成类爆炸，主要原因是单品+调料组成造成类爆炸问题，因此可以将调料内置到Drink中，这样就不会造成类数量过多，从而提高项目的维护性(如图所示)。

说明：milk、soy、chocolate可以设置成boolean型，表示是否需要添加。

方案二可以控制类的数量，一定程度上解决了类爆炸问题，但没有遵守ocp原则，尤其在新增一种调料时，需要修改代码。考虑到要添加多份调料时，可以将hasMilk返回对应的int型就可以了。可以考虑装饰者模式！

装饰者模式基本介绍：

1. 装饰者模式：动态的将新功能添加到对象中，在对象功能扩展方面，他比继承者更有弹性。装饰者模式也体现了ocp原则。
2. 这里提到的动态的将新功能添加到对象和ocp原则，在后面的实际应用中以代码的形式体现。

装饰者模式原理：

1. 装饰者模式就像打包一个快递。
2. 主体是比如说：陶瓷、衣服（Component）
3. 包装：比如：报纸、泡沫、塑料、纸板、木板（Decorator）
4. Component主体：比如说前面的drink。
5. ConreteComponent和Decorator：ConreteComponent：具体的主体，比如说前面的各种单品咖啡。
6. Decorator：装饰者，比如说各种调料。
7. 在如图的Component和ConreteComponent之间，如果ConreteComponent类很多，可以设计一个缓冲层，将共有的部分提取出来，抽象成一个类。

用装饰着模式的设计方案

说明：drink就是前面的抽象类Component，Decaf就是前面的单品咖啡，Decorator是一个装饰者，含有一个被装饰的对象Drink。

装饰者模式下的订单：2份巧克力+一份牛奶的LongBlack

说明：Milk包含了LongBlack，一份Cholocate包含了Milk+LongBlack，一份Cholocate包含了Cholocate+Milk+LongBlack，这样不管什么形式的单品咖啡+调料组合，都可以通过递归的方式方便的组合和维护。

装饰者模式在JDK应用中的源码分析：

java的IO结构，FilterInputStream就是一个装饰者。

InputSteam是个抽象类，实现的是Closeable接口，类似于抽象者模式中的Component。

FilterInputStream继承了InputStream，是一个装饰者Decorator

DataInputSteam是装饰者FilterInputStream的子类。

如代码所示：