标签： 设计模式初涉
描述性文字
还记得工厂方法模式小猪开的奶茶店吗？在那一节中讲解的是
通过工厂方法模式来做奶茶，做奶茶的工作都已经交给小弟了，
小猪的工作量少了很多，剩下的就是敲起二郎腿坐着收钱了，
于是乎列了一张单子，写出所有饮品的价格：
奶茶：
- 原味奶茶：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
网友评论