设计模式是被发现的，而非发明。
装饰者模式
定义
动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案
设计原则
- 开放-关闭原则；应当对扩展开放，对修改关闭
使用场景举例
我们有个基类beverage(饮料)，此时我们需要根据用户的喜好，向饮料中添加各种调料，sugar(糖)、milk(奶)等，并计算价钱。
分析
不使用装饰者模式的情况下，我们要怎么实现如上需求呢？
- 是不是这样：定义类beverage，包含变量 price; 再定义类 sugar、milk都包含其自己的price 代码如下
class beverage{
constructor(something={}) {
this.price = something.price||0+20;
}
}
class sugar{
constructor() {
this.price = 5;
}
}
class milk{
constructor() {
this.price = 8;
}
}
let beverageSugar = new beverage(new sugar());
let beverageMilk = new beverage(new milk());
console.log(beverageSugar.price); //=>25
console.log(beverageMilk.price); //=>28
看起来，上面的方法好像没什么问题，但是别忘了，我们面对的可是用户，我们要牢记一句话用户并非恶意的，但一定是无知的
此处的无知，并非贬义词，而是说用户对你的程序无知，并且他们也不关心你的程序。于是，用户A说，我要一杯加三份糖的饮料。而用户B又说我要一份奶再加一份糖
哦豁，完蛋。。。。
现在，我们的装饰者模式有了用武之地，let us see see
示例代码如下
// 饮料 被装饰者
class Beverage{
constructor() {
this.price = 20;
this.name = "空饮料"
}
const(){
return this.price
}
}
// 糖 装饰器
class Sugar{
// 装饰器传入当前饮料，保存价格与配料
constructor(beverage) {
this.beverage = beverage;
this.name = this.beverage.name+"+sugar"
}
condiment(){
return this.name
}
const(){
// 材料糖的价格为5
return 5+this.beverage.const()
}
}
// 奶 装饰器
class Milk{
// 装饰器传入当前饮料，保存价格与配料
constructor(beverage) {
this.beverage = beverage;
this.name = this.beverage.name+"+milk"
}
condiment(){
return this.name
}
const(){
// 材料奶的价格为8
return 8+this.beverage.const()
}
}
// 创建空饮料
let a = new Beverage();
// 加奶
a = new Milk(a);
// 加奶
a = new Milk(a);
// 加糖
a = new Sugar(a);
console.log(a.condiment()) //=>空饮料+milk+milk+sugar
console.log(a.const()) //=>41
我们使用JS来演示，其他语言思路相通，示例仅做基础演示，主要为突出此设计模式思想
问题
当然，我们的基础示例代码会附带一些问题，比如我们会创建很多的小类，现在是Sugar、Milk,后面如果还需要其他各种各样的装饰器呢？
问题自然是可以解决的，后面我们会学到工厂模式。即可解决这个问题。
总结一下
装饰者模式：我们需要有被装饰者与装饰者，装饰者通过保存被装饰者当前状态，并添加新的状态，来完成装饰。
基于文章开头我们说的设计原则：开放-关闭原则，我们可以任意扩展装饰者，而被装饰者的状态时不允许被修改的。
最后
代码是死的，人是活的，写代码的过程中，我们会发现很多种设计模式的变种，依照设计思路的不同，需求的不同，我们要灵活的运用设计模式，我们最终的目的，是为了设计出弹性的、可复用的、可维护的项目。
