设计模式 - 装饰者模式

预设场景

假设我们要开一家新的咖啡店，并为这个咖啡店设计一个订单系统。开店之初，饮品种类不多，只有拿铁Latte， 浓缩咖啡Espresso，卡布奇诺Cappuccino三种，所以该系统的品类设计就比较简单。如图：

每个子类实现cost()方法来返回饮料的价格。
随着咖啡店发展，仅仅咖啡单品已经不能满足客户的需求了，客户还希望能够自由地选择添加一些辅料，比如牛奶Milk，奶泡Whip，巧克力Mocha等等，而这些辅料也会给咖啡店增加一定的成本，所以我们决定按照客户添加的辅料另外增加咖啡饮品的价格。

1. 设计方法一：

我们首先尝试根据添加辅料的不同，我们创建不同的类，每个类的cost()方法将其价格算出来：

很明显，这样的设计很糟糕，简直是类爆炸，代码复用性低，同时开发人员维护起来很困难。为了改善类爆炸这个坑，我们有另外一种设计方法。

2. 设计方法二：
   在父类Beverage中加入判断是否存在辅料的方法

这样，算子类价格比如Espresso，cost()方法可以遍历Espresso所有辅料的hasXXX()方法，如果有添加该辅料就返回辅料价格，否则返回0，最后将所有辅料价格加上去。例如：

这样的设计看起来舒服一些，但是细想一下，似乎仍然存在一些问题，万一辅料的价格改了，我们还需要修改Beverage类中每个hasXXX()方法，这违反了我们的设计原则

设计原则
类应该对扩展开放，对修改关闭

另外有些顾客想要加两倍的辅料，那么hasXXX()返回的价格似乎就不对了。
我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。如果能实现这样的目标，该设计就可以弹性的应对改变，可以接受新的功能带来的改变需求。

认识装饰者模式

从刚才的运用场景我们已经认识到，单纯的利用继承无法完全的解决问题，在设计咖啡店的订单系统的时候，我们遇到了类爆炸， ** 设计死板**，以及在基类加入新功能并不适用于所有的子类。
所以，我们在这里可以采用不一样的做法，我们以咖啡饮品（Beverage）本身作为主体，然后在运行时用辅料牛奶（Milk），奶泡（whip），巧克力（Mocha）来装饰饮品。比方说，顾客要点一杯拿铁，加牛奶和巧克力，此时我们需要做的是：

1. 创建一个拿铁（Latte）对象实例
2. 拿牛奶（Milk）来装饰它
3. 拿巧克力（Mocha）来装饰它
4. 调用cost()方法，依赖委托将调料价格加上去

这过程就类似一个俄罗斯套娃，一层一层套上去，每套一层，做一些改变。

• 装饰者和被装饰对象拥有相同的超类Beverage
• 我们可以用一个或者多个装饰者来装饰原始对象
• 用装饰过的对象来代替原始对象
• 装饰者可以在所委托被装饰者的行为之前/之后，加上自己的行为，以达到特定的目的
• 对象可以在任何时候被装饰，所以可以在运行时动态地，不限量地增加喜欢的装饰者来装饰原始对象

装饰者模式动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更加有弹性的替代方案

代码Demo：咖啡店订单系统

• 饮品抽象类:

public abstract class Beverage {
   

    protected String description = "Unkonwn Beverage";

    public String getDescription() {
   
        return description;
    }

    public abstract double cost();

}

• 辅料抽象类:

//装饰者
public abstract class