装饰（者）模式
典型应用：服务端存盘机制，Save()，Load()
模式描述：替代继承，用一个类去装饰另一个类，动态地给被装饰的类添加新的职责，形成一个装饰链
现实案例：一个手抓饼，决定它价格的因素有很多，比如加个鸡蛋，加个里脊，加个蔬菜，加个牛排，加个肉松，价格都是不同的，而不是每一个手抓饼都有鸡蛋，里脊，蔬菜，牛排，肉松的，有些可能还要加双份鸡蛋，对于原味手抓饼而言，它并不需要任何与调料有关的逻辑，所以将所有调料独立出去，在需要的时候才用调料去装饰手抓饼，形成一个新的手抓饼，比如加一个鸡蛋，就用鸡蛋类去装饰手抓饼，再加一个里脊，就用里脊类去装饰鸡蛋手抓饼，如果还要再加一个鸡蛋，就再用鸡蛋类装饰一遍，最后的手抓饼生成后，工厂模式
就以鸡蛋->里脊->鸡蛋->手抓饼 的顺序依次统计价格，披萨也是同理的例子
又比如游戏中的一把铁剑，开锋，精炼+10，附魔+10，强化锻造+10，镶嵌宝石，圣光加持，玄铁融合，天雷淬炼，龙血浇灌，天神赐福，魂印附着，法阵烙印，道纹加深，符文雕刻，最后成为一把九天十地威武超然辟魔弑仙屠圣2018特别加强版神剑，这些加成都是装饰器，然后用这柄神剑去砍怪，一刀下去计算伤害的时候，会顺着装饰器一个一个轮流计算下去，最终返回伤害能力，加成多的就多几层装饰，加成少的就少几层装饰，但是无论装饰有多少，都不用修改铁剑本身的代码，只是在外面附加装饰
将装饰的部分功能从类的核心功能中分离出来，采用层层包装的方式装饰出最终的结果
In My Opinion：但是装饰者模式有一个问题，在使用装饰者模式的时候，真正对外可见的是包装在最外层的一个装饰类，而这个装饰类和被装饰类并不一定是同一个类，所以在使用装饰类去修改代码时，如果原代码是针对具体类编写的，在装饰完之后可能会出现问题
所以装饰模式一般会和工厂模式，生成器模式一起使用，让装饰模式在诞生时就自动化地被使用好，而比较少地在已有代码上添加装饰模式