为了防止被“杀”了祭天，学点设计模式，并总结下还是有必要的。
一：理解
- 顾名思义，装饰者模式可以在不修改基础类的前提下，增加/修改对象的属性。
- 提到装饰者模式，立即想到《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代码，逻辑清晰。
