I walk very slowly, but I never walk backwards 设计模式 - 装饰者模式
寂然
大家好，我是寂然，本节课，我们来聊设计模式中的装饰者模式，当然，首先，来一杯塞纳河畔，左岸的咖啡☕️
案例需求 - 星巴克咖啡
来看一个星巴克咖啡订单项目需求：
- 咖啡种类/单品咖啡：Espresso（意大利浓咖啡）、Cappuccino（卡布奇诺）、Cafe Latte（冰拿铁）
- 配料：Milk、sugar
客户可以点单品咖啡，也可以单品咖啡+配料，根据客户订单计算不同种类咖啡的费用
要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便
解决方案一：一般实现
针对上面的需求，我们一般想到的实现方式是定义一个基类Coffee，然后让各种单品咖啡去继承基类 Coffee，重写里面的description() 和 cost() 方法，当然咖啡里还可以加东西，同样我们可以使用这种方式，就是把咖啡和每一种配料，进行组合，类图如下：
其实这种思路我们不需要去实现，大家很容易就会发现，这样去做，整个项目的可维护性和可扩展性非常差，如果咖啡店新增加了一种单品咖啡，数量就会倍增，因为咖啡里还可以加东西，那就会出现类爆炸问题，所以这种方法可以实现业务逻辑，但是考虑到扩展和维护起来太差，不符合需求，所以不可取
解决方案二：配料改进
OK，前面我们分析，使用方案一解决咖啡订单项目，由于客户可以点单品咖啡加任意配料，所以使用方案一会造成类的倍增，扩展性和可维护性都非常差，因此我们需要进行改进，那有的小伙伴说了，我们可以把配料内置到Coffee 类中，这样就不会造成类的数量倍增了，我们来看下简易类图
方案二我们把配料内置到Coffee 类中，那各种单品咖啡重只需要继承Coffee类即可，可以根据返回值来确定是否要添加各种类型的配料，例如 hasSugar() 方法返回int类型，那某一个单品咖啡重写该方法，返回 0 表示不加糖，返回1或者其他表示加的糖的份数，然后cost() 方法完成计费即可，这样就不会造成类的数量倍增，新增单品咖啡添加一个类即可，项目的可维护性提高了
方案分析
但其实方案二也存在一些问题，虽然方案二控制了类的数量，不至于造成类爆炸，但是针对配料而言，按照方案二的思路，每一种配料都需要提供has() 方法和 set() 方法，考虑到实际上咖啡中可以加的配料有很多，那在对配料种类进行维护（CRUD）的时候，代码量还是很大，所以虽然方案二针对扩展性和维护性较方案一而言，有了很大的提升，但是也不是咖啡订单项目的最优解，那铺垫了这么久，这里就可以引出我们的主角 - 装饰者模式了
基本介绍
装饰者模式：在不改变原有对象的基础之上，动态的将功能附加到对象上，提供了比继承更有弹性的替代方案（扩展原有对象功能） ，装饰者模式也体现了开闭原则（ocp）
这里提到的动态的将新功能附加到对象和 ocp 原则，在后面的应用实例上会以代码的形式体现
原理类图
其实上面的概念比较抽象，我们换一种思路，结合装饰者模式的原理类图，我们来理解装饰者模式
装饰者模式就类比于大家打包一个快递，比如我们要给朋友打包邮寄一个笔记本电脑，肯定不能直接邮寄，需要装在纸箱里，并且外面包裹快递袋，其实这里的笔记本电脑就是主体 - Component，也就是装饰者模式中的被装饰者，而纸箱以及快递袋就是包装 - Decorator 即装饰者，所以根据类图，我们可以抽象出装饰者模式的一些角色
装饰者模式角色
- Component 主体：定义一个主体的模板，类比前面星巴克项目的基类 Coffee
- ConcreteComponent：具体的主体， 类比前面的各类单品咖啡
- Decorator：装饰者，类比咖啡中的各种配料，（根据类图的思路可以看到，装饰者里面聚合了主体即被装饰者是一种反向的思维，后面代码中大家就能体会到这样设计的好处）
- ConcreteDecoratorA /B：具体的装饰角色，负责具体的装饰细节
当然，在如图的 Component 与 ConcreteComponent 之间，如果 ConcreteComponent 类很多,还可以设计一个缓冲层，将共有的部分提取出来，再抽象出一层
解决方案三：装饰者模式
类图展示
抽象基类Coffee，就是装饰者模式角色中主体
Espresso 等就是具体的单品咖啡，即ConcreteComponent
Decorator 是装饰者，聚合了被装饰者 Coffee
Decorator 的cost() 方法会采用递归的方式，进行费用的叠加计算
装饰者模式下订单思路
为何需要递归呢？假设现在客户下了一单咖啡，点了卡布奇诺加一份 milk 加两份 sugar ,那其实是这样的思路
1）里层，Milk包含了 Cappuccino ，sugar包含了 Milk + Cappuccino
2）再加一份糖，就是 sugar包含了 sugar + Milk + Cappuccino
3）这样不管是什么形式的单品咖啡加配料，通过递归方式都可以方便的组合和维护
代码演示
//主体/被装饰者
public abstract class Coffee {
private String desc; //描述
private float price = 0.0f;
public String getDesc() {
return desc;
}
public void setDesc(String desc) {
this.desc = desc;
}
public float getPrice() {
return price;
}
public void setPrice(float price) {
this.price = price;
}
//计算费用的抽象方法，子类来实现
public abstract float cost();
}
//卡布奇诺
public class Cappuccino extends Coffee {
public Cappuccino(){
setDesc("卡布奇诺");
setPrice(24.0f);
}
@Override
public float cost() {
return super.getPrice();
}
}
//意大利浓咖啡
public class Espresso extends Coffee{
public Espresso(){
setDesc("意大利浓咖啡");
setPrice(18.0f);
}
@Override
public float cost() {
return super.getPrice(); //对于单品咖啡而言
}
}
//装饰者
public class Decorator extends Coffee {
//聚合被装饰者
private Coffee coffee;
public Decorator(Coffee coffee){
this.coffee = coffee;
}
//重写计费方法
@Override
public float cost() {
return super.getPrice() + coffee.cost();
}
@Override
public String getDesc() {
return super.getDesc() + coffee.getDesc();
}
}
//牛奶
public class Milk extends Decorator{
public Milk(Coffee coffee) {
super(coffee);
setDesc("牛奶");
setPrice(3.0f);
}
}
//糖
public class Sugar extends Decorator {
public Sugar(Coffee coffee) {
super(coffee);
setDesc("方糖");
setPrice(2.0f);
}
}
//咖啡店（客户端）
public class CoffeeStore {
public static void main(String[] args) {
//点了卡布奇诺加一份 milk 加两份 sugar
//先有卡布奇诺
Coffee order = new Cappuccino(); //订单还没结束
// System.out.println(order.cost());
// System.out.println(order.getDesc());
//加入一份牛奶 直接放进去， 使用装饰者模式
order = new Milk(order);
// System.out.println(order.cost());
//
// System.out.println(order.getDesc());
//加入一份糖
order = new Sugar(order);
// System.out.println(order.cost());
// System.out.println(order.getDesc());
//再加入一份糖
order = new Sugar(order);
System.out.println(order.cost());
System.out.println(order.getDesc());
}
} 设计优势
在当前模式下，如果我们要新增一种单品咖啡，你会发现，继承 Coffee类就可以用了，同样，新增一种配料也是如此，那这样设计的扩展性是非常优秀的，而且非常灵活，我可以随意单点或者加各种配料，组合多少都无所谓，是完成星巴克咖啡订单比较优质的解法之一
装饰者模式VS继承
- 装饰者模式与继承关系的目的都是要扩展对象的功能，但是装饰者模式可以提供比继承更多的灵活性，装饰者模式允许系统动态决定“贴上”一个需要的“装饰”，或者除掉一个不需要的“装饰，继承关系则不同，继承关系是静态的，它在系统运行前就决定了，
- 如果采用装饰者模式，相对继承而言，需要类的数目就会大大减少 ，因为如果都是用继承的方法实现的，那么每一种组合都需要一个类，就会造成大量性能重复的类出现，当然， 在另一方面，使用装饰模式会产生比使用继承关系更多的对象
JDK - IO源码解析
装饰者模式在Java语言中的最著名的应用莫过于Java I/O标准库的设计了，下面，我们一起来看下装饰者模式在IO源码里的应用，由于Java I/O库需要很多性能的各种组合，如果这些性能都是用继承的方法实现的，那么每一种组合都需要一个类，这样就会造成大量性能重复的类出现，而如果采用装饰者模式，那么类的数目就会大大减少，性能的重复也可以减至最少，因此装饰者模式是Java I/O库的基本模式
在Java的IO结构中，FilterInputStream 扮演的就是装饰者的角色，简图如下所示
下面我写一段测试代码，进入源码来梳理下装饰者模式的使用流程
public class Test {
public static void main(String[] args) throws Exception{
DataInputStream dis = new DataInputStream(new FileInputStream("d:\\jiran.txt"));
dis.read();
dis.close();
}
} 部分源码拷贝，放到代码块中展示出来，如图所示
//可以看到，FileInputStream是InputStream的子类
public
class FileInputStream extends InputStream
{
/* File Descriptor - handle to the open file */
private final FileDescriptor fd;
//可以看到，InputStream是抽象类
public abstract class InputStream implements Closeable {
//可以看到，FilterInputStream内部聚合了InputStream，即被装饰者
public
class FilterInputStream extends InputStream {
/**
* The input stream to be filtered.
*/
protected volatile InputStream in;
//可以看到，DataInputStream是FilterInputStream的子类
public
class DataInputStream extends FilterInputStream implements DataInput { 源码说明
- 抽象类 InputStream，类比星巴克案例中的被装饰者 Coffee
- FileInputStream是InputStream的子类，类比星巴克案例中的各种单品咖啡，是具体的主体
- FilterInputStream内部聚合了InputStream，扮演装饰者的角色，类比星巴克案例中的Decorator
- DataInputStream是FilterInputStream的子类，是具体的装饰者，类比星巴克案例中的Milk/Sugar
所以，在JDK的IO体系中，使用到了装饰者模式
下节预告
OK，到这里，装饰者模式的相关内容就结束了，下一节，我们开启组合模式的学习，希望大家能够一起坚持下去，真正有所收获，就像开篇那句话，我走的很慢，但是我从来不后退，哈哈，那我们下期见~