如何让孩子爱上设计模式 ——8.装饰者模式(Decorator Pattern)

标签： 设计模式初涉

描述性文字

还记得工厂方法模式小猪开的奶茶店吗？在那一节中讲解的是
通过工厂方法模式来做奶茶，做奶茶的工作都已经交给小弟了，
小猪的工作量少了很多，剩下的就是敲起二郎腿坐着收钱了，
于是乎列了一张单子，写出所有饮品的价格：

奶茶：

• 原味奶茶：5块
• 珍珠奶茶：7块
• 椰果奶茶：7块
• 珍珠椰果奶茶：9块

柠檬茶：

• 原味柠檬茶：3块
• 金桔柠檬茶：5块

然后顾客要什么点什么，按着菜单收费就好了，然而用户的
需求都是多变的，他们觉得配料那里可以加点红豆，然后你
的菜单需要新增：

• 红豆奶茶：7块
• 红豆珍珠奶茶：9块
• 红豆椰果奶茶：9块
• 红豆珍珠椰果奶茶：11块

食客又说，还可以加点其他的配料啊，黑钻，果冻，凉粉，奶盖，
烧仙草等，然后你的菜单就爆炸了，奶盖果冻黑钻烧仙草珍珠椰果奶茶，
2333，你仿佛特意在逗我笑，

每个组合都写一个，这他么得写多少个，而且用户总是
天马行空的，哪天希望配料加点 ，也是有可能的，
每多一种配料，就得增加一堆饮品，玩毛。

我们必须想一个更优的套路，这个时候可以考虑引入装饰者模式，
简单来说就是：一层套一层，比如说要椰果珍珠奶茶：

奶茶 –> 套一层珍珠 –> 珍珠(奶茶) –> 套一层椰果 –> 椰果(珍珠(奶茶))

逼逼那么多，代码演示下吧！

代码实现

先定义一个抽象茶的父类，定义茶的名字与定义价格的抽象方法

接着定义配料的抽象类，所有配料都来继承这个东东

好的，接着定义基本茶品，奶茶和柠檬茶

接着是各种配料，珍珠，椰果，红豆，金桔，都是继承配料类

接着开始自由搭配了：

打单：

可以，没毛病，如果你要奶盖果冻黑钻烧仙草珍珠椰果奶茶，也无压力，
没新增一个配料就建一个类而已，不用每次都去新建一堆类，然后又
去继承。

模式要点

定义：

动态的给对象添加一些额外的职责，就增加功能来说，装饰者
模式比起生成子类更加灵活！

四个角色：

• Component：抽象组件，可以是接口或抽象类，具体组件与抽象装饰类
  的共同父类，声明了在具体组件中实现的业务方法，可以使客户端以一致的方式
  处理未修饰对象与修饰后的对象，实现了客户端的透明操作，比如这里的Tea类。
• ConcreteComponent：具体组件，实现抽象组件中生命的方法，装饰器
  类可以给他增加额外的责任(方法)，比如这里的MilkTea和LemonTea。
• Decorator：抽象装饰类，装饰组件对象的，内部一定要有一个指向
  组件对象的引用！！！通过该引用可以调用装饰前构建对象的方法，并通过
  其子类扩展该方法，已达到装饰的目的，比如这里的Decorator类。
• ConcreteDecorator：具体装饰类，抽象装饰类的具体实现，可以调用抽象
  装饰类中定义的方法，也可以新增新的方法来扩充对象的行为。

UML类图

适用场景

装饰者模式是以对客户端透明的方式扩展对象的功能，是继承关系的一种替代方案！
以下情况可以考虑是想用对象组合（组合与委托）：

• 在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责；
• 处理那些可以撤消的职责；
• 当不能采用生成子类的方法进行扩充时：一种情况是，可能有大量独立的扩展，
  为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况
  可能是因为类定义被隐藏，或类定义不能用于生成子类；

优缺点

• 扩展对象功能，比继承灵活，不会导致类个数急剧增加；
• 可以通过一种动态的方式在运行时选择不同的具体装饰类，从而实现不同的行为；
• 避免了高层次类有太多的特征，可以从一个最简单的类慢慢给他添加功能；
• 会产生很多小装饰者对象，会影响性能，过多使用该模式也会使程序变得复杂。

本节代码：

https://github.com/coder-pig/DesignPatternsExample/tree/master/7.Decorator%20Pattern