装饰者模式

装饰者模式

小蓝杯、谁不爱

当我知道“小蓝杯”瑞幸咖啡前段时间（2019.6）在美国上市了，然后就去买了一杯试了下（首次免费），表示喝不习惯。今天我们就来研究下，怎么计算咖啡的金额。

V1版本

我们知道，咖啡有很多种类，不同的种类售价是不一样的，基于我们面向对象的知识，非常自然的会抽象出来一个饮料基类（除了咖啡，其他饮料也包括进来了），然后提供一个抽象的计算价格的方法，具体的咖啡类实现自己的价格计算，基于此，我们来实现V1版本。

饮料基类

/**
 * 饮料基类
 */
public abstract class Beverage {
    private String description;

    /**
     * 计算价格方法
     * @return
     */
    public abstract double cost();

    public String getDescription() {
        return description;
    }

    public void setDescription(String description) {
        this.description = description;
    }
}

脱因咖啡实现

/**
 * 脱因咖啡
 */
public class Decaf extends Beverage {
    @Override
    public double cost() {
        return .82d;
    }
}

深度烘焙咖啡实现

/**
 * 深度烘焙咖啡
 */
public class DarkRoast extends Beverage {
    @Override
    public double cost() {
        return 1.05d;
    }
}

嗯，非常简单，一点不复杂。

然而，在购买咖啡时，也可以要求加入各种调料，如加奶、加糖、加摩卡（巧克力风味）等，有没有加盐的咖啡？额，没试过。

我们试试直接通过扩展子类的类别看看，简单的两种咖啡和三种调料会组合出来多少子类。加奶脱因咖啡，加糖脱因咖啡，加摩卡脱因咖啡，加奶加糖脱因咖啡，加奶加摩卡脱因咖啡，加糖加摩卡脱因咖啡，加奶加糖加摩卡脱因咖啡。同样，深度烘焙咖啡组合调料后也有7个子类。这样，两种咖啡混合三种调料，算上不加任何调料的类型，总共会有16种类型（2的4次方），
大家可以想象，如果新增一种咖啡，或者新增一种调料，子类会指数级增长，就问你怕不怕。

所以，直接扩展子类的方式肯定是不科学的，那要如何解决这种问题呢？既然继承不合适，那么按照组合/聚合原则，我们使用组合的方式来重新设计V2版，咖啡组合调料。

V2版本

首先，我们将调料单独提取出来，抽象出一个调料基类，它也有价格和说明方法。

/**
 * 调料基类
 */
public interface FlavouringV2 {

    String getName(); //调料名称

    float cost(); //调料价格
}

然后提供调料的具体实现，如奶、糖、摩卡。

/**
 * 奶
 */
public class MilkV2 implements FlavouringV2{
    @Override
    public String getName() {
        return "白白的牛奶";
    }
    @Override
    public float cost() {
        return 1.2f;
    }
}
/**
 * 糖
 */
public class SugarV2 implements FlavouringV2{
    @Override
    public String getName() {
        return "甜甜的糖";
    }
    @Override
    public float cost() {
        return 2.15f;
    }
}
/**
 * 摩卡
 */
public class MochaV2 implements FlavouringV2{
    @Override
    public String getName() {
        return "摩卡-巧克力风味";
    }
    @Override
    public float cost() {
        return 1.15f;
    }
}

在饮料基类中组合调料，因为调料可能是0或者多个，所以使用调料的列表，在计算价格中，加入调料的价格计算。

/**
 * 饮料基类
 */
public abstract class BeverageV2 {
    private String description;

    private List<FlavouringV2> flavourings; //调料列表

    public BeverageV2() {
        flavourings = new ArrayList<>();
    }

    /**
     * 添加调料
     * @param flavouring
     */
    public void addFlavouring(FlavouringV2 flavouring){
        flavourings.add(flavouring);
    }

    /**
     * 计算调料价格
     * @return
     */
    public float costFlavouring(){
        //将所有调料的价格汇总返回
        return flavourings.stream().map(f -> f.cost()).reduce((c1,c2) -> c1+c2).orElse(0.0f);
    }

    /**
     * 计算价格方法
     * @return
     */
    public abstract float cost();

    public String getDescription() {
        String flavouringNames = combineFlavouringNames();
        String concatString = flavouringNames.isEmpty() ? ", " : ",加了 ";
        return description + concatString + flavouringNames;
    }

    private String combineFlavouringNames() {
        return flavourings.stream().map(f -> f.getName()).reduce((name1,name2) -> name1+","+name2).orElse("");
    }

    public void setDescription(String description) {
        this.description = description;
    }
}

具体的饮料类（咖啡），需要调用父类的计算调料价格的方法。

/**
 * 脱因咖啡
 */
public class DecafV2 extends BeverageV2 {
    public DecafV2() {
        setDescription("脱因咖啡");
    }

    @Override
    public float cost() {
        return 6.82f + costFlavouring();
    }
}
/**
 * 深度烘焙咖啡
 */
public class DarkRoastV2 extends BeverageV2 {
    public DarkRoastV2() {
        setDescription("深度烘焙咖啡");
    }
    @Override
    public float cost() {
        return 9.05f + costFlavouring();
    }
}

好了，我们来测试一波

/**
 * V2版测试
 */
public class CafeMainV2 {
    public static void main(String[] args) {
        //点一杯脱因咖啡，什么都不加
        BeverageV2 cafe1 = new DecafV2();
        System.out.println(cafe1.getDescription() + " 需要" +cafe1.cost()+"元");

        //点一杯脱因咖啡，加奶
        BeverageV2 cafe2 = new DecafV2();
        cafe2.addFlavouring(new MilkV2());
        System.out.println(cafe2.getDescription() + " 需要" +cafe2.cost()+"元");

        //点一杯脱因咖啡，加奶,加糖
        BeverageV2 cafe3 = new DecafV2();
        cafe3.addFlavouring(new MilkV2());
        cafe3.addFlavouring(new SugarV2());
        System.out.println(cafe3.getDescription() + " 需要" +cafe3.cost()+"元");
    }
}

结果

脱因咖啡,  需要6.82元
脱因咖啡,加了 白白的牛奶 需要8.02元
脱因咖啡,加了 白白的牛奶,甜甜的糖 需要10.17元

妥妥的没问题。

V2版UML图

如果，现在添加一种咖啡饮料，只需要扩展新的饮料子类，它可以组合各种调料，而不需要修改任何其他类；
同理，若要新添加一种调料，只需要扩展新的调料子类，它可以被加入到各种饮料中，而不需要修改任何其他类，因此符合开闭原则。

这里再一次验证了设计原则的重要性，设计原则是内功，设计模式是招式。
上面这个UML图看起来像是组合了策略模式和观察者模式，发现这两种招式一融合，就创建一个新的招式，这个新的招式叫"桥接模式"。
哈哈，这个模式可不是今天要给大家介绍的。

V3版本

现在，我们换一种思路来解决问题，看看今天的主角 装饰者模式 是怎么解决这个问题的。这就是V3版。
我们以饮料为主体，使用调料来装饰饮料，比如我们要点一杯加奶的脱因咖啡，那么首先我们有一个DecafV3对象，然后使用MilkDecorator对象去装饰它（包装），调用cost方法时，先调用外部装饰者的cost方法，它内部调用被装饰者的cost方法，会形成一条与装饰顺序相反的调用链，将价格累积起来。

看看装饰者模式实现的代码
饮料主体结构一样：

/**
 * 饮料基类
 */
public abstract class BeverageV3 {
    private String description;

    /**
     * 计算价格方法
     * @return
     */
    public abstract float cost();

    public String getDescription() {
        return description;
    }

    public void setDescription(String description) {
        this.description = description;
    }
}

/**
 * 脱因咖啡
 */
public class DecafV3 extends BeverageV3 {
    public DecafV3() {
        setDescription("脱因咖啡");
    }

    @Override
    public float cost() {
        return .82f;
    }
}

/**
 * 深度烘焙咖啡
 */
public class DarkRoastV3 extends BeverageV3 {
    public DarkRoastV3() {
        setDescription("深度烘焙咖啡");
    }
    @Override
    public float cost() {
        return 1.05f;
    }
}

饮料装饰者抽象，装饰者本身的类型要与饮料主体的类型一致，因此需要继承至饮料基类。同时其内部需要包装被装饰者对象。

/**
 * 调料装饰者抽象
 */
public abstract class FlavouringDecoratorV3 extends BeverageV3 {
    BeverageV3 beverage; //被装饰对象

    public FlavouringDecoratorV3(BeverageV3 beverage) {
        this.beverage = beverage;
    }

    public BeverageV3 getBeverage() {
        return beverage;
    }

    public void setBeverage(BeverageV3 beverage) {
        this.beverage = beverage;
    }

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

具体装饰者，会调用被装饰者的方法。

/**
 * 糖装饰者
 */
public class SugarDecoratorV3 extends FlavouringDecoratorV3{

    public SugarDecoratorV3(BeverageV3 beverage) {
        super(beverage);
        setDescription("甜甜的糖");
    }

    @Override
    public float cost() {
        return 2.15f + beverage.cost();
    }
}

/**
 * 奶装饰者
 */
public class MilkDecoratorV3 extends FlavouringDecoratorV3{

    public MilkDecoratorV3(BeverageV3 beverage) {
        super(beverage);
        setDescription("白白的奶");
    }

    @Override
    public float cost() {
        return 1.2f + beverage.cost();
    }
}

测试走起

/**
 * V3版测试
 */
public class CafeMainV3 {
    public static void main(String[] args) {
        //点一杯脱因咖啡，什么都不加
        BeverageV3 cafe1 = new DecafV3();
        System.out.println(cafe1.getDescription() + " 需要" +cafe1.cost()+"元");

        //点一杯脱因咖啡，加奶
        BeverageV3 cafe2 = new DecafV3();
        FlavouringDecoratorV3 milkDecorator = new MilkDecoratorV3(cafe2);
        System.out.println(milkDecorator.getDescription() + " 需要" +milkDecorator.cost()+"元");

        //点一杯脱因咖啡，加奶,加糖
        BeverageV3 cafe3 = new DecafV3();
        milkDecorator = new MilkDecoratorV3(cafe3);
        FlavouringDecoratorV3 sugarDecorator = new SugarDecoratorV3(milkDecorator);
        System.out.println(sugarDecorator.getDescription() + " 需要" +sugarDecorator.cost()+"元");
    }
}

输出结果

脱因咖啡 需要0.82元
加白白的奶, 脱因咖啡 需要2.02元
加甜甜的糖, 加白白的奶, 脱因咖啡 需要4.17元

就是这么优雅，就是这么艺术范。

V3版UML图

如果要新增咖啡类型，只需要扩展饮料子类，它可以被各种调料装饰者装饰，不会修改现有其他类，同理，若要新增调料，只需要扩展调料装饰者子类，它就可以去装饰其他饮料类型，不会修改现有其他类，满足开闭原则。

定义

理解了上面的这个例子，我们来看下装饰者的官方定义：
装饰者模式动态的将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

实际上，装饰者模式这招，还是从设计原则（组合/聚合原则和依赖倒置原则）的内功创造出来的。内功是关键，什么时候达到无招胜有招，招式就可随手拈来。

我们用代码来实现下
抽象类型

/**
 * 抽象组件
 */
public interface Component {
    void methodA();
}

具体实现

/**
 * 具体组件
 */
public class ConcreteComponent implements Component {
    @Override
    public void methodA() {
        System.out.println("具体组件实现方法A");
    }
}

装饰者抽象

/**
 * 抽象装饰者
 */
public abstract class Decorator implements Component{
    Component component; //被装饰对象

    public Decorator(Component component) {
        this.component = component;
    }
}

具体装饰者

/**
 * 具体装饰者A
 */
public class ConcreteDecoratorA extends Decorator {
    public ConcreteDecoratorA(Component component) {
        super(component);
    }

    @Override
    public void methodA() {
        System.out.println("具体装饰者A开始装饰.." );
        component.methodA();
        System.out.println("具体装饰者A装饰结束.." );
    }
}
/**
 * 具体装饰者B
 */
public class ConcreteDecoratorB extends Decorator {
    public ConcreteDecoratorB(Component component) {
        super(component);
    }

    @Override
    public void methodA() {
        System.out.println("具体装饰者B开始装饰.." );
        component.methodA();
        System.out.println("具体装饰者B装饰结束.." );
    }
}

测试

/**
 * 测试
 */
public class DecoratorMain {
    public static void main(String[] args) {
        Component component =
                new ConcreteDecoratorB(new ConcreteDecoratorA(new ConcreteComponent()));
        component.methodA();
    }
}

输出

具体装饰者B开始装饰..
具体装饰者A开始装饰..
具体组件实现方法A
具体装饰者A装饰结束..
具体装饰者B装饰结束..

UML图

JDK的装饰者

在JDK中，我们的I/O框架就大量使用了装饰者模式。
其中InputStream为抽象组件，FileInputStream、ByteArrayInputStream为具体组件。
FilterInputStream就是我们的装饰者父类了，BufferedInputStream、DataInputStream为实现了具体装饰功能的装饰者。
看看UML图（部分）

我们来试一下，扩展个小写装饰器，来对读取的字母装换成小写。

/**
 * 小写装饰器
 */
public class LowerCaseInputStream extends FilterInputStream {

    protected LowerCaseInputStream(InputStream in) {
        super(in);
    }

    @Override
    public int read() throws IOException {
        int c = super.read();
        return (c == -1 ? c : Character.toLowerCase(c));
    }

}

测试

/**
 * IO测试
 */
public class IOMain {
    public static void main(String[] args) throws IOException {
        InputStream is =
                new LowerCaseInputStream(new BufferedInputStream(new StringBufferInputStream("THIS is The TEST text")));
        int c ;
        while((c = is.read()) > 0){
            System.out.print((char)c);
        }
    }
}

扩展示例

按照惯例，我们继续来看一个示例，加深理解。示例来源：https://java2blog.com/decorator-design-pattern/
说，一个房间，我们可以通过颜色和窗帘去装饰它，当我使用不同装饰器的时候，看到的房间效果是不一样的。
废话少说，直接上代码。

抽象的组件（房间)

/**
 * 房间
 */
public interface Room {
    String showRoom();
}

具体组件（一个毛坯房）

/**
 * 毛坯房
 */
public class SimpleRoom implements Room{
    @Override
    public String showRoom() {
        return "毛坯房";
    }
}

装饰者父类

/**
 * 房间装饰器（装饰器父类）
 */
public class RoomDecorator implements Room {

    //被装饰的房间
    protected Room specialRoom;

    public RoomDecorator(Room specialRoom) {
        this.specialRoom = specialRoom;
    }

    @Override
    public String showRoom() {
        return specialRoom.showRoom();
    }
}

颜色装饰器

/**
 * 颜色装饰者
 */
public class ColorDecorator extends RoomDecorator{
    public ColorDecorator(Room specialRoom) {
        super(specialRoom);
    }

    @Override
    public String showRoom() {
        return specialRoom.showRoom() + addColors();
    }

    private String addColors() {
        return " 被涂成蓝色 ";
    }
}

窗帘装饰器

/**
 * 窗帘装饰者
 */
public class CurtainDecorator extends RoomDecorator {
    public CurtainDecorator(Room specialRoom) {
        super(specialRoom);
    }

    @Override
    public String showRoom() {
        return specialRoom.showRoom() + addCurtains();
    }

    private String addCurtains() {
        return " 挂上红色的窗帘 ";
    }
}

测试

/**
 * 测试
 */
public class DecoratorDesignPatternMain {
    public static void main(String args[]) {
        Room room = new CurtainDecorator(new ColorDecorator(new SimpleRoom()));
        System.out.println(room.showRoom());
    }
}

装饰效果：

毛坯房 被涂成蓝色  挂上红色的窗帘 

一不小心就变成设计师了，真棒。

观察下UML图

有没有感觉很清晰了。

装饰者模式这个招式，和后面我们要学习的适配器模式、代理模式的招式有异曲同工之妙（使用包装），所以理解了一个，对其他的也就非常容易理解了。

再次强调，招式不是关键，内功才是。

源码

https://gitee.com/cq-laozhou/design-pattern