设计模式之“装饰者模式”

装饰者模式

定义：指在不改变现有对象结构的情况下，动态地给该对象增加一些指责（即增加其额外功能）的模式，它属于对象结构型模式。

• 装饰器是继承的有力补充，比继承灵活，在不改变原有对象的情况下，动态的给一个对象扩展功能，即插即用
• 通过使用不用装饰类及这些装饰类的排列组合，可以实现不同效果
• 装饰器模式完全遵守开闭原则

其主要缺点是：装饰器模式会增加许多子类，过度使用会增加程序得复杂性。

模式的结构

装饰器模式主要包含以下角色。

1. 抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象。
2. 具体构件（ConcreteComponent）角色：实现抽象构件，通过装饰角色为其添加一些职责。
3. 抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
4. 具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

装饰器模式的结构图如图所示：

案例

星巴克咖啡订单项目（咖啡馆）：
1）咖啡种类/单品咖啡：Espresso(意大利咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)
2）调料：Milk、Soy(豆浆)、Chocolate
3) 要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便
4）使用OO的来计算不同种类咖啡的费用：客户可以点单品咖啡，也可以单品咖啡+调料组合。

方案一

方案设计如图：

问题分析

• Drink 是一个抽象类，表示饮料。
• des 就是对咖啡的描述，比如咖啡的名字。
• cost() 方法就是计算费用，Drink 类中做成一个抽象方法。
• Decaf 就是单品咖啡，继承Drink，并实现cost。
• Espress && Milk就是单品咖啡+调料，这个组合很多。
• 这样设计，会有很多类，当我们增加一个单品咖啡，或者一个新的调料类的数量就会倍增，就会出现类爆炸。

方案二

前面分析到方案1因为咖啡单品+调料组合会造成类的倍增，因此可以做改，将调料内置到Drink类，这样就不会造成类数量过多。从而提高项目的维护性（如图）

问题分析

• 方案2可以控制类的数量，不至于造成很多的类。
• 在增加或者删除调料种类时，代码的维护量很大。
• 在考虑到用户可以添加多份调料时，可以将hasMilk返回一个对应int。
• 考虑使用装饰者模式

方案三（装饰模式）

方案设计如图：

分析

这里主体跟实体大致不变，主要在抽象主体与调料中间添加了一个中间层。中间层的作用就是在调用cost的时候，他是要进行费用的叠加的，还有一个重要的就是中间层引入了一个Drink对象，这个对象其实包含着被装饰的对象，这个被装饰的对象，在调用coat的时候我们会获取他的费用，然后通过递归的放方式去获取这一级所有费用、同时具体装饰的名字可以通过getDescription（）获取。就是外面包装那么多东西，也可以获取出来。

例如
装饰者模式下的举例订单：2份巧克力+一份牛奶的LongBlack

代码实现

抽象类

public abstract class Drink {
   

    public String des;//描述
    private float price = 0.0f;

    public String getDes() {
   
        return des;
    }

    public void setDes(String des) {
   
        this.des = des;
    }

    public float getPrice() {
   
        return price;
    }

    public void