学好设计模式防被祭天：装饰者模式

作者: 阿菜的博客 | 来源:发表于2017-08-27 07:41 被阅读117次

装饰者模式

为了防止被“杀”了祭天，学点设计模式，并总结下还是有必要的。

一：理解

顾名思义，装饰者模式可以在不修改基础类的前提下，增加/修改对象的属性。
提到装饰者模式，立即想到《Head First 设计模式》中，奶茶的例子。
装饰者模式的新建过程大致为A a = new C(new B(new A()))。
无论装饰多少层，都可以赋值给a对象，表示装饰者和被装饰者属于同一个继承体系。

二：例子

你是个低调的富二代，不抽烟，不喝酒，没事就喜欢在街头走一走，喔哦哦，你会把手揣进裤兜。

火爆的奶茶店

有一天，你发现街边有一家叫一丢丢的奶茶店超级火爆。

于是，你决定投资一个亿，开一家饮料店。

你叫来程序员小菜帮忙设计饮料店系统。

小菜自称一把梭，上来就是干，立马新建了一个饮料基类，如下：

public abstract class Drink {
    
    public abstract String getDesc();

    public abstract double getCost();
}

饮料基类拥有两个抽象方法，一个返回饮料名称，一个返回饮料价格。

一开口就知道是老江湖了

看到小菜这么积极主动，并且用上了抽象类。你也装作很懂的样子，说了句：一上手就知道是老江湖了。

于是你很放心地让小菜设计接下来的内容。

你的需求是：

饮料店会售卖4种饮料，包括奶茶(MilkTea)，咖啡(Coffee)，果汁(Juice)，苏打水(Soda)。
可以在饮料上加奶泡(Whip)，糖霜(Sugar)，珍珠(Pearl)。

小菜觉得饮料的种类和加料不是很多，三下五除二就把整个程序给搞定了。

// 奶茶类
public class MilkTea extends Drink {
    @Override
    public String getDesc() {
        return "奶茶";
    }

    @Override
    public double getCost() {
        return 10;
    }
}

// 奶茶加奶泡类
public class MilkTeaWithWhip extends Drink {
    @Override
    public String getDesc() {
        return "奶茶加奶泡";
    }

    @Override
    public double getCost() {
        return 10 + 2;
    }
}

// 奶茶加奶泡加糖霜类
public class MilkTeaWithWhipAndSugar extends Drink {
    @Override
    public String getDesc() {
        return "奶茶加奶泡加糖霜";
    }

    @Override
    public double getCost() {
        return 10 + 2 + 1;
    }
}

// 奶茶加奶泡加糖霜加珍珠类
public class MilkTeaWithWhipAndSugarAndPearl extends Drink {
    @Override
    public String getDesc() {
        return "奶茶加奶泡加糖霜加珍珠";
    }

    @Override
    public double getCost() {
        return 10 + 2 + 1 + 1;
    }
}

// 奶茶加糖霜类
// 奶茶加糖霜加珍珠类
// ……
// 咖啡加XXX类
// ……

搞定了奶茶MilkTea类，奶茶可以不加料，加一种料，两种料，三种料，一共是1 + 3 + 3 + 1 = 8个类。

小菜接着搞定咖啡，果汁，苏打水类，一种是4 * 8 = 32个类，加上基类Drink，一共是33个类。

下班

于是，小菜在一片需求不饱和的议论声中，在六点准时下班了，并期待第二天得到富二代的表扬。

饮料店顺利开张了，和意料中的一样，生意超级火爆。

多了一个奶茶店店主title的你，很是高兴，一有空就去隔壁老王的奶茶店调研。

你发现王叔叔奶茶店可以让顾客选择不同的甜度，从不加糖加十分甜，一共11个等级。

你觉得很有创意，于是你迫不及待地叫小菜加上这个功能。

小菜没多想，立马答应了下来，并表示在做完手头的需求之后，立马就做。

夜深人静，小菜拿出键盘，准备一段敲。

突然发现，原来有32个类，每个类都需要扩展成从0级甜度到10级甜度。

一算下来，类会被扩展到32 * 11=352。

不过富二代第二天就要看到结果，小菜还是决定先做完功能性需求再说。

于是啪啪啪一顿敲，终于写完了这352个类。

然而第二天，小菜接到通知，糖霜的价格上涨，加糖霜从一块变成了两块。

不会全文搜索的小菜修改了所有加了糖霜的饮料类之后，累翻在电脑桌前。

尽管如此，小菜还是忘改了一个奶茶加糖霜加A加B加C加D加E加F……类。

在收益计算的时，你发现少了一些钱，瞬间感觉自己损失了两个亿。

于是准备杀了这位程序员祭天。

小菜急忙解释道自己立马开始重构，一个类就能搞定。

@Data
public class DrinkRe {
    private boolean hasWhip;
    private boolean hasSugar;
    private boolean hasPearl;
    private int sugarIndex;
    private int cost;
    private String name;

    public DrinkRe(boolean hasWhip, boolean hasSugar, boolean hasPearl, int sugarIndex, int cost, String name) {
        this.hasWhip = hasWhip;
        this.hasSugar = hasSugar;
        this.hasPearl = hasPearl;
        this.sugarIndex = sugarIndex;
        this.cost = cost;
        this.name = name;
    }

    public String getDesc() {
        StringBuilder drinkDesc = new StringBuilder();
        drinkDesc.append(name);
        if (hasWhip) {
            drinkDesc.append("加奶泡");
        }
        if (hasSugar) {
            drinkDesc.append("加糖霜");
        }
        if (hasPearl) {
            drinkDesc.append("加珍珠");
        }
        if (sugarIndex >= 0) {
            drinkDesc.append(sugarIndex + "分甜");
        }
        return drinkDesc.toString();
    }

    public double getSumCost() {
        int sumCost = cost;
        if (hasWhip) {
            sumCost += 2;
        }
        if (hasSugar) {
            sumCost += 2;
        }
        if (hasPearl) {
            sumCost += 1;
        }
        return sumCost;
    }

    public static void main(String[] args) {
        DrinkRe coffee = new DrinkRe(true, true, true, 7, 10, "咖啡");
        System.out.println(coffee.getDesc());
        System.out.println(coffee.getSumCost());
    }
}

这个饮料类在构造时传入基础饮料的名称和价格，并在输出描述和价格之前都先判断是否有加料。

又过了几天，饮料店愈发火爆，你开始提出新的需求：

饮料增加20种。
加料增加30种。
加糖霜描述之后加上(木糖醇)字样，以示很健康。

小菜想了下：

一个类的情况在构造饮料时，每次都要手动输入饮料的名字和价格。
hasXXX，在DrinkRe中增加30个属性，一个好长的构造函数。
需要写n多个if判断语句。
需求三倒是容易搞定，但又担心之后又要改回来。

于是，一脸懵X的小菜请教了资深老司机，老司机先开了一会车，不紧不慢地告诉他，装饰者模式可以解决这个问题。

装饰者模式包含：

基类Drink，申明了饮料类有getDesc和getCost两个方法。
被装饰者，如基础款奶茶MilkTea，实现了两个抽象方法。
装饰者，加了糖霜的饮料DrinkWithSugar，该类不关心把糖霜加在奶茶还是咖啡上，只负责把糖霜加载饮料上。
DrinkWithSugar包含一个Drink属性，在构造函数中，就设置传入的drink对象。
DrinkWithSugar继承自Drink父类，即使加了糖霜之后，它也还是一杯饮料。
DrinkWithSugar重写getDesc和getCost方法，分别加上“加糖霜(木糖醇)”字样，和加上糖霜的价格。

// 饮料基类
public abstract class Drink {

    public abstract String getDesc();

    public abstract double getCost();
}

// 被装饰者
public class MilkTea extends Drink {

    @Override
    public String getDesc() {
        return "奶茶";
    }

    @Override
    public double getCost() {
        return 10;
    }
}

// 装饰者类
public class DrinkWithSugar extends Drink {

    private Drink drink;

    public DrinkWithSugar(Drink drink) {
        this.drink = drink;
    }

    @Override
    public String getDesc() {
        return drink.getDesc() + "加糖霜(木糖醇)";
    }

    @Override
    public double getCost() {
        return drink.getCost() + 2;
    }
}

// 测试
public class Client {
    public static void main(String[] args) {
        Drink drinkWithSugar = new DrinkWithSugar(new MilkTea());
        System.out.println(drinkWithSugar.getDesc());
        System.out.println(drinkWithSugar.getCost());
    }
}

输入/输出：

奶茶加糖霜(木糖醇)
12.0

用上装饰者模式之后，整个系统不需要修改，只需要添加新的类。

在需要增加新的饮料时，只需添加一个新的饮料类，如Milk。

在需要增加新的加料时，也只需要加一个新的加料类，如DrinkWithSugarFree，用于做加糖免费活动。

在快速的新品，活动迭代下，隔壁王叔叔奶茶店倒闭了。

作为富二代的你看了很高兴，准备好好奖励下小菜。

奶茶店小妹也向程序员投来了崇拜的眼神，上来就是一顿酥麻酥麻的夸奖。

然而，第二天，程序员就看到奶茶店小妹出现在了富二代的跑车里。

当然是选择原谅他了

三：再理解

装饰者模式是对继承的再思考。
加料之后，还是一杯饮料，被装饰者和装饰者都继承自同一个父类。
对修改关闭，对添加开放，符合设计原则，添加新功能只需增加少量代码。
避免了大量的if else代码，逻辑清晰。

网友评论

程序员

本文标题：学好设计模式防被祭天：装饰者模式

本文链接：https://www.haomeiwen.com/subject/eacbdxtx.html

延伸阅读

深度阅读

您也可以注册成为美文阅读网的作者，发表您的原创作品、分享您的心情！