设计模式之装饰模式（2）--有意思的想法

背景

这是我第二次写装饰模式，这一次是在上一次的基础上进一步探究装饰模式，这一次有了很多新的感受和想法，也多了很多趣味性的内容，读完一定让你觉得写代码原来这么有意思。还是简单介绍一下装饰模式的概念，如果想了解更基础更详细的内容，可以先读一下我的第一篇装饰模式的博客：设计模式之装饰模式–优雅的增强

概述

概念

装饰模式（Decorator Pattern）是一种结构型设计模式，动态地给一个对象添加一些额外的功能，就增加功能来说，装饰模式比生成子类更为灵活。
在这里插入图片描述
这张图今天将反复出现，先来对照概念来一一认识一下这上面的每一个类

角色

在装饰模式中，通常涉及以下几个重要角色（请对照概念和类图）：

抽象组件（Component）
抽象组件定义了被装饰对象和装饰对象的共同接口。
具体组件（Concrete Component）
具体组件是实现了抽象组件接口的类，它是装饰的目标对象（要增加额外职能的类）。
抽象装饰器（Decorator）
抽象装饰器是一个包含了与抽象组件相同接口的成员变量，并从抽象组件继承的类。它的职责是在调用原始对象之前或之后，执行额外的操作（增加的额外职能的父类）。
具体装饰器（Concrete Decorator）
具体装饰器是实现了抽象装饰器接口的类，它包装了具体组件，并可以在调用前后执行额外的操作（增加的具体的额外职能）。

总结一下:这种图昨天的类是要增加额外职能的类，右边一坨是要增加的额外职能。

打个比方，左边的具体组件（Concrete Component）和右边要增加的职能抽象装饰器（Decorator）本来毫不相干，但是现在非要把它们往一起凑（非要变成一家人），怎么办，那就找了一个义父（抽象组件（Component）），强硬的变成了一家人（同一个义父的子类）

基本代码分析

抽象组件：(定义的规范：子类如何实现的规范)

public interface Component {void operation();
}

具体组件：

public class ConcreteComponent implements Component {@Overridepublic void operation() {System.out.println("具体组件的操作");}
}

抽象装饰器：
这是关键类，里面一共三部分，一个Component 类型的属性，一个setComponent方法，用来给属性赋值，这里使用了多态，参数Component component，看起来接受的是一个Component 类型的变量，但是自始至终，接受的只是Component 的子类（ConcreteComponent ）和孙类（ConcreteDecoratorA 和ConcreteDecoratorB），用两个词语里形容就是 认贼作父和认孙做父！这个放到后面细说。第三部分是重写的父类方法，调的是传进来的Component类型的变量的operation方法。

public abstract class Decorator implements Component {protected Component component;public void setComponent(Component component) {this.component = component;}@Overridepublic void operation() {if (component != null) {component.operation();}}
}

具体装饰器A：
这两个具体的装饰类继承自Decorator ，同时也继承自Component （双层继承），这里的重点是operation方法中的super.operation();也就是这个方法让整个装饰的过程按照正确顺序串联起来。
ConcreteDecoratorA 中增加了一个属性，也就是给被装饰对象增加的额外职责。
ConcreteDecoratorB中增加了一个方法，给给装饰对象增加的额外职责。
这两个类算是从两个维度，告诉我们如何给被装饰对象增加额外职责的。

public class ConcreteDecoratorA extends Decorator {private String addedProperty;@Overridepublic void operation() {super.operation();addedProperty="New State";System.out.println("具体装饰器A的操作);}}

具体装饰器B：

public class ConcreteDecoratorB extends Decorator {@Overridepublic void operation() {super.operation();addedMethod();}public void addedMethod() {System.out.println("具体装饰器B的操作");}
}

客户端使用：

ConcreteComponent c= new ConcreteComponent();
ConcreteDecoratorA d1= new ConcreteDecoratorA();
ConcreteDecoratorB d2= new ConcreteDecoratorB();d1.setComponent(c);
d2.setComponent(d1);
ConcreteDecoratorB.operation();

客户端里先实例化了三个对象
第一对象C是要装饰的原有对象。
后面两个对象是具体的装饰对象。

重点来了：我来说一下下面代码的执行顺序，不要眨眼**

d1.setComponent ( c ) 这句代码执行的时候会先到ConcreteDecoratorA 类中，没有找到setComponent 方法，因此会向它的父类Decorator 中找，然后把C对象传递给Decorator 的component属性
同样，d2.setComponent(d1)执行的时候，会把装饰了C对象的d1对象传递给Decorator 的component属性。这里一定要注意是装饰了C对象的d1对象。

接下来，执行ConcreteDecoratorB.operation();
会先到ConcreteDecoratorB找到operation方法，这个方法里的第一句是super.operation();
在这里插入图片描述
是先执行父类Decorator 的operation方法，这个方法里先判空，然后执行component的operation，这个时候要注意，这个component是刚刚上面传进来的d1,

此时会d1是ConcreteDecoratorA 类型的，那又回到了ConcreteDecoratorA 中执行operation方法，接下来和刚才一样，执行父类Decorator 的operation方法，判空，然后执行component的operation，这个component是刚刚上面传进来的c，c是ConcreteComponent 类型，然后执行ConcreteComponent 里面的operation方法，打印“具体组件的操作”，后面就是一路返回，怎么来的怎么回去。

输出结果为：

具体组件的操作
具体装饰器A的操作
具体装饰器B的操作

❀❀花样重难点

聚合关系

还是这张图
红框框住的两部分，被装饰对象和具体装饰对象加起来是Component （儿子和孙子的抽象），也就是聚合关系的箭头所指，他们加起来聚合到了Decorator ，这是形式上的聚合，在代码中并没有体现（关于这一点还有待探究）
那么为什么不是Decorator自聚合呢，如果是自聚合，只是代表Decorator是具体装饰的容器，那么就不能把服饰包装到ConcreteComponent 上了
在这里插入图片描述
关于上面的解释在代码中的体现就是Decorator类中的Component 类型的参数

这里引出来我的下一个问题

认贼作父和认孙做父

Component 本来是Decorator的父类，但是在代码的实际运行中，传的只有ConcreteComponent 和ConcreteDecoratorA 和ConcreteDecoratorB。
ConcreteComponent 相对于Decorator来说是同辈份。（认贼作父）
ConcreteDecoratorA 和ConcreteDecoratorB都是Decorator的子类。（认孙做父）

客户端的优化及好处

在这里插入图片描述
这三段代码，可以看到引用都是子类型的，其实完全是可以用父类型去接
先问个问题，这三个实例都可以使用Component去接吗？
不要被迷惑住了，虽然他们都继承自Component，但是Component里可是没有setComponent方法的，所以只有new ConcreteComponent()可以用Component接。
代码可以改成:

Component c= new ConcreteComponent();
Decorator d1= new ConcreteDecoratorA();
Decorator d2= new ConcreteDecoratorB();

这样写有什么好处呢？
多客户端的复用
比如后两句都用Decorator 去接，=号右边完全可以使用配置文件，动态new对象，如果把没一句都看成一个按钮背后的逻辑，每个按钮都是一个客户端，放到页面上就实现了并行。重复的代码就可以使用自动生成。

继承到设计模式的演变过程

最后再说一个我自己的想法，仅供参考
还记得开头概念中说过的“就增加功能来说，装饰模式比生成子类更为灵活”，就先来说说继承，如果我们想给一个类增加功能，如果不在原有类中增加代码的话，可以使用继承的形式增加新的代码，那先看下面的图中左边的图，这个例子是设计模式书上的给人穿衣服的例子，如果不清楚，可以参照我的上一篇博客中的代码，链接在最上面。
加入TShirt是要给Person增加的功能，那么可以使用继承。左边的图。
那么根据封装变化点（这是面向对象的精髓），现在是增加了一个TShirt，我又想增加一个其他的类TShirt2，你会怎么做，会抽出一个父类，遵循依赖倒置原则，会让Person和接口Finery产生关系，就变成了右边的图
在这里插入图片描述

同样的道理，现在被装扮类不止一个Person,我也想给Animal装扮。那么就给Person和Animal抽出一个父类Component,遵循依赖倒置原则，会让Finery和接口Component产生关系，就变成了右边的图。现在看这张图和我开篇放的那张装饰模式的图是不是基本一致了，只是缺少了聚合关系。
关于聚合关系，在业务实现过程中并没有体现，这点以后有机会再研究。

在这里插入图片描述