前言

距离上一篇，间隔时间有点长哈(尴尬 ==!)
经历过漫长的实习期，试用期，第一份工作终于慢慢走上正轨，中间发生了很多事情，有好有坏，回头看看，也不能说谁对谁错，只是立场不同罢了，都是选择罢了。
废话不多说，开始进入今天的主题，装饰器模式。

设计模式分类

• 有说分为3类的：创建型，结构型(装饰器模式属于这种)，行为型 —— 参考设计模式总结之模式分类一文；
• 也有说分成5类的：接口型模式，职责型模式，构造型模式，操作型模式，扩展型模式(装饰器模式属于这种) —— 参考(给自己备忘)常用的5类23种设计模式一文。

唔，我觉的都行，互补的看吧。

相关概念

• 定义：装饰模式是一种对象结构型模式
• 功能：动态地给一个对象增加一些额外的职责(也就是扩展)
• 优点：比生成子类实现更为灵活，比直接修改该类更符合开放关闭原则
• 缺点：装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得很复杂，最好配合工厂或生成器这样的模式一起使用

情景代入

好吧，概念什么的太枯燥了，还是喜欢简单粗暴的方式，直接情景代入。哦，这里推荐 Head First 系列哈，有的图我就直接拿来用了。

额，我不懂咖啡，也不喜欢喝，太苦。+ +
所以，不要用什么分类错误，不懂咖啡这点来怼我哈，小心脏，受不来哦 + +

如下图，咖啡厅里有饮料(抽象类)，有各种咖啡(4个子类)，都有一个计算价格的cost()继承自Beverage类。

饮料及其子类

需求变化

• 假设，这个时候需要多加一种新咖啡，就意味着，需要有一个新的子类，同时需要复写cost()，对吧？那如果多加10种咖啡呢？100种呢？可以预见的是，随着咖啡厅业务的发展，咖啡种类，越来越多，子类的是数量会爆炸的！！！

后来发现，这里的“种”有歧义，稍微解释一下，现实生活中，拿铁，摩卡等算是一种咖啡，但是在代码里，配料的组合方式不同，就是不同种类的咖啡。
比如：拿铁咖啡，配牛奶，配糖，为种类一；
     拿铁咖啡，配豆浆，配糖，就为种类二；
     拿铁咖啡，配豆浆*2，配糖，就为种类三；
排列组合计算一下，有多少种咖啡，就有多少子类 +_+

• 假设，配料的价格发生变化，比如牛奶的涨价了，那么所有含有牛奶的咖啡价格都会发生变化，相应的cost()需要修改，这个改动可是很大的！！！

针对以上两点，我们发现继承的确很好的使得，所有子类都拥有和父类一样的cost()行为，但是在代码的可维护性上表现的并不好，这个时候，我们可以尝试组合(装饰)的方式。

初识装饰器

我们已经了解单独利用继承无法完全解决问题，所以，在这里要采用不一样的做法：我们要以饮料为主体，然后在需要时以配料来装饰(decorate)饮料。比方说，如果顾客想要加摩卡和奶泡的深焙咖啡，那么，要做的是:

1. 获取一个深焙咖啡(DarkRoast)对象
   DarkRoast

2. 以摩卡(Mocha)对象装饰它
   Mocha Wrap

3. 以奶泡(Whip)对象装饰它
   Whip Wrap

4. 调用cost()方法，将调料的价钱加上去，得出总价
   cost().png

装饰器模式关键点

• 装饰者和被装饰对象有相同的超类型。

关于这个，我需要解释一下，相同的超类行，是为了保证类型一致。
我们需要装饰者必须能取代被装饰者，才能被下一个装饰者叠加装饰。
继承在通常的情况下有两个功能，1.类型匹配 2.获得行为。这里用的是第一个功能。

• 你可以用一个或多个装饰者包装一个对象。
• 既然装饰者和被装饰对象有相同的超类型，所以在任何需要原始对象(被包装的)的场合， 可以用装饰过的对象代替它。
• 装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的 —— 最关键的点。
• 对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。

结构梳理

整体结构设计

代码实现

1. 自然是Beverage类(被装饰者)了

/**
 * 饮料的基类
 */
public abstract class Beverage {

    /**
     * 饮料的描述
     */
    String description = "饮料(基类)";

    public String getDescription() {
        return description;
    }

    /**
     * 计算总价：
     * v1：饮料本身的价格+原材料的价格
     * v2：饮料本身的价格+原材料的价格*数量
     * v3：饮料本身的价格+原材料的价格*数量+杯子的大小容量(小杯，大杯)
     */
    public abstract double cost();
}

2. 为了简单，我就只写两个子类哈

public class Decaf extends Beverage {

    public Decaf() {
        description = "低咖啡因咖啡";
    }

    @Override
    public double cost() {
        return 1.05; //该咖啡本身的价格
    }
}

public class DarkRoast extends Beverage {

    public DarkRoast() {
        description = "深焙咖啡";
    }

    @Override
    public double cost() {
        return 0.99; //该咖啡本身的价格
    }
}

3. 配料(装饰者)的基类

/**
 * 基础配料(装饰者)
 */
public abstract class CondimentDecorator extends Beverage {

    /**
     * 由子类去实现，返回具体的描述
     */
    public abstract String getDescription();
}

4. 为了简单，我也只写两个哈

public class Milk extends CondimentDecorator {

    Beverage beverage;

    /**
     * 关键点，装饰者的构造器中，需要把被装饰的对象传进来
     */
    public Milk(Beverage beverage) {
        this.beverage = beverage;
    }

    /**
     * 描述，先把之前的装饰行为描述出来，再追加这次的
     */
    @Override
    public String getDescription() {
        return beverage.getDescription() + ", 牛奶";
    }

    /**
     * 价格也一样，先把之前的价格累加，再追加这次的
     */
    @Override
    public double cost() {
        return beverage.cost() + 0.10;
    }
}

public class Soy extends CondimentDecorator {

    Beverage beverage;

    public Soy(Beverage beverage) {
        this.beverage = beverage;
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + ", 豆浆";
    }

    @Override
    public double cost() {
        return  beverage.cost() + 0.15;
    }
}

5. 接下来，就是看结果的时候了

public class StarbuzzCoffee {

    public static void main(String[] args) {

        Beverage beverage1 = new Espresso();
        System.out.println(beverage1.getDescription() + " $" + beverage1.cost());

        Beverage beverage2 = new DarkRoast();
        beverage2 = new Mocha(beverage2);
        beverage2 = new Mocha(beverage2);
        beverage2 = new Whip(beverage2);
        System.out.println(beverage2.getDescription() + " $" + beverage2.cost());

        Beverage beverage3 = new HouseBlend();
        beverage3 = new Soy(beverage3);
        beverage3 = new Mocha(beverage3);
        beverage3 = new Whip(beverage3);
        System.out.println(beverage3.getDescription() + " $" + beverage3.cost());
    }
}

6. 结果如图
   关于有强迫症的同学们，不希望“摩卡”出现两次，一些要写成“摩卡*2”才舒服的话，需要自己去改写 CondimentDecorator 中 getDescription()，使其返回 ArrayList 类型，让每个配料名称独立，那么 CondimentPrettyPrint() 会更容易编写e。

   
   
   image.png
7. 总结一下
   装饰器 = 继承(被装饰者：咖啡) + 组合(行为) + 继承(配料：牛奶)

开-闭原则

之前提到过，开放-关闭原则，这里简单说一下：类应该对扩展开放，对修改关闭。

• 面对快速变化的千奇百怪的需求(程序猿永远的痛)，扩展性的重要性就不必多说了
• 关闭修改，对于之前写好的代码， 经过了测试同学的努力，终于确认相对安全后，最好最好最好不要再次修改，复制粘贴都别，以防万一！！！如果你对这点有疑问，你应该去找你的经理谈谈心～～

Java I/O

这是一个最常见的运用装饰器模式的案例。直接上图。

Java I/O

再多说几句

• 采用装饰者在实例化组件时，将增加代码的复杂度。一旦使用装饰者模式，不只需要实例化组件，还要把此组件包装进装饰者中，天晓得有几个，就像这样：

Beverage beverage2 = new DarkRoast();
beverage2 = new Mocha(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
...
要写多少次？所以，要借助工厂(Factory)模式和生成器(Builder)模式配合使用

• 我在学习过程中，这样的说法：
  • 并不是所有可以使用适配器模式的地方，都必须去使用，要根据成本去抉择使用与否。额，这句话就是需要大量的项目经验才能去衡量平衡了，我目前说不清楚。
  • 如果代码写成依赖于具体的组件类型，那么装饰者就会导致程序出问题。只有在针对抽象组件类型编程时，才不会因为装饰者而受到影响。这句话，我也不是很理解，感觉很玄学 + +
• 哦，对了对了，差点忘记了，这个装饰器模式和Kotlin中的扩展函数有点相似，当然后者简洁的多，有兴趣的朋友可以去看看～～