设计模式之装饰模式（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产生关系，就变成了右边的图。现在看这张图和我开篇放的那张装饰模式的图是不是基本一致了，只是缺少了聚合关系。
关于聚合关系，在业务实现过程中并没有体现，这点以后有机会再研究。

总结

    装饰模式算比较难的设计模式了，进行了多次学习，每次学习都有不一样的收获，而且越来越有意思，希望今天的文章也能带给你同样的感受。如果你也有有意思的想法和不同意见，欢迎指教，最后感谢阅读。