【设计模式（九）】结构型模式之装饰器模式

个人学习笔记分享，当前能力有限，请勿贬低，菜鸟互学，大佬绕道

如有勘误，欢迎指出和讨论，本文后期也会进行修正和补充

前言

中秋刚过没多久，虽然我这种粗人对月饼无感，但是公司发的肯定得收的嘛

拿回家当零食吃算了，一个硬纸袋，打开是一个盒子，盒子打开时十多个小盒子，小盒子打开是塑料包装的月饼，撕开塑料包装，终于能吃了

吃了一口，emmm就这？还没小时候吃的冰糖五仁月饼好吃呢，弄这么花里胡哨

就一块味道并不咋地的月饼，花里胡哨包装一层又一层，何必呢？还不如改善工艺做好吃点

说的再难听点，这些精心包装的月饼，跟普通袋装的月饼，区别也就只是包装吧（虽然大部分人送的是心意）

包装对于月饼，就只是装饰而已，差不多做法生产的月饼，经过一层又一层包装，就能变成在店铺里形形色色的礼品月饼，本质上依然是月饼

而且理论上包装可以无限层的套娃。。。。

我们早上去早餐店买煎饼，可以加鸡蛋、生菜、肉松等等，从一个薄饼整成一个巨无霸，但说到底，仍然是个煎饼。

装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。

这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。

添加了新功能后是原对象的子类，根据==里氏代换原则==，新的对象也能够被再次修饰，进而可以无限套娃**

1.介绍

使用目的：向一个现有的对象添加新的功能，同时又不改变其结构

使用时机：在不想改变结构的情况下扩展类

解决问题：避免扩展时常规继承方法，随着扩展功能的增多，子类会很膨胀

实现方法：Component类充当抽象角色，修饰类引用和继承 Component 类，具体扩展类重写父类方法，而修饰类也同样可被扩展

应用实例：

• 买手抓饼的时候，我们并非只有做之前可以说加什么，做完之后加肉松，或者加火腿什么的都是可以的，但怎么加都是手抓饼
• 化妆的时候，经常是涂涂抹抹好几层，而且顺序并不严格固定，也可以最后根据情况再涂几层，怎么好看怎么来，但怎么涂都是自己的脸

优点：

1. 装饰类和被装饰类可以独立发展，不会相互耦合
2. 可以被多次装饰，使用时自由度高

缺点：多层装饰时思路比较复杂，需要清晰的理解业务

2.结构

通常包括4个角色

• 抽象组件角色(Component): 定义可以动态添加任务的对象的接口
• 具体组件角色(ConcreteComponent)：定义一个要被装饰器装饰的对象，即 Component的具体实现
• 抽象装饰器(Decorator): 维护对组件对象和其子类组件的引用，需要实现 Component
• 具体装饰器角色(ConcreteDecorator)：向组件添加新的职责

image-20201026091625651

• ConcreteComponent负责Component的具体实现
• Decorator是一个虚拟类，需要实现Component，并持有一个Component对象
• ConcreteDecorator作为装饰器，负责给组件添加职责

ConcreteDecorator作为Decorator的子类，根据==里氏代换原则==，也可被ConcreteDecorator持有并装饰**

说白了就是，==我装饰我自己==

3.实现

1. 定义抽象组件角色(Component)

   interface Component {
       String operate();
   }
   

2. 定义具体组件角色(ConcreteComponent)，并实现Component

   class ConcreteComponent implements Component {
   
       @Override
       public String operate() {
           return "原始对象";
       }
   }
   

3. 定义抽象装饰器(Decorator)，实现Component

   abstract class Decorator implements Component {
       private Component component;
   
       public Decorator(Component component) {
           this.component = component;
       }
   
       @Override
       public String operate() {
           //调用被装饰者的方法
           return component.operate();
       }
   }
   

4. 定义具体装饰器角色(ConcreteDecorator)，继承Component

   class ConcreteDecoratorA extends Decorator {
   
       public ConcreteDecoratorA(Component component) {
           super(component);
       }
   
       @Override
       public String operate() {
           return super.operate() + " 加上修饰器A";
       }
   }
   
   class ConcreteDecoratorB extends Decorator {
   
       public ConcreteDecoratorB(Component component) {
           super(component);
       }
   
       @Override
       public String operate() {
           return super.operate() + " 加上修饰器B";
       }
   }
   

5. 测试客户端

   public class DecoratorTest {
       public static void main(String[] args) {
           Component component = new ConcreteComponent();
           Component componentA=new ConcreteDecoratorA(component);
           Component componentAB=new ConcreteDecoratorB(componentA);
           Component componentABA=new ConcreteDecoratorA(componentAB);
   
           Component componentBAB=new ConcreteDecoratorB(new ConcreteDecoratorA(new ConcreteDecoratorB(new ConcreteComponent())));
   
           System.out.println(componentABA.operate());
           System.out.println(componentBAB.operate());
   
       }
   

完整代码

package com.company.test.decorator;

interface Component {
    String operate();
}

class ConcreteComponent implements Component {

    @Override
    public String operate() {
        return "原始对象";
    }
}

abstract class Decorator implements Component {
    private Component component;

    public Decorator(Component component) {
        this.component = component;
    }

    @Override
    public String operate() {
        //调用被装饰者的方法
        return component.operate();
    }
}

class ConcreteDecoratorA extends Decorator {

    public ConcreteDecoratorA(Component component) {
        super(component);
    }

    @Override
    public String operate() {
        return super.operate() + " 加上修饰器A";
    }
}

class ConcreteDecoratorB extends Decorator {

    public ConcreteDecoratorB(Component component) {
        super(component);
    }

    @Override
    public String operate() {
        return super.operate() + " 加上修饰器B";
    }
}

public class DecoratorTest {
    public static void main(String[] args) {
        Component component = new ConcreteComponent();
        Component componentA=new ConcreteDecoratorA(component);
        Component componentAB=new ConcreteDecoratorB(componentA);
        Component componentABA=new ConcreteDecoratorA(componentAB);

        Component componentBAB=new ConcreteDecoratorB(new ConcreteDecoratorA(new ConcreteDecoratorB(new ConcreteComponent())));

        System.out.println(componentABA.operate());
        System.out.println(componentBAB.operate());

    }
}

运行结果

image-20201026104004926

4.小结

4.1.为何要使用装饰模式

1. 解耦ConcreteComponent和ConcreteDecorator，从常见的继承关系变为关联关系，使他们可以独立变化，只需要遵守共同的规则（Component）即可

   否则只能使他们一层一层继承，耦合度极高，不利于扩展

2. ConcreteComponent和ConcreteDecorator都算是Component的实现，因此对于Component适用的接口，ConcreteComponent和ConcreteDecorator都适用，这样以来，客户端使用和外部接口对接也会简单很多

   因此外部代码只需要针对Component设计即可

3. 可以自己装饰自己，是独一无二的优点，可以无限制的自由增加功能

4.2.存在的隐患

均为设计或者管理不当导致，也就是人为错误，可以凭借开发者能力规避的东西

1. 套娃次数太多，会导致逻辑混乱

   比如server层之间的互相引用，很容易出现套娃，逻辑极其混乱

2. 死循环

   类似于递归的死循环爆栈

3. 装载顺序报错（先有鸡还是先有蛋？）

   比如两个service（A和B）互相引用，那么装载A时需要先装载B，装载B时需要先装载A，会直接报错

后记

我装饰我自己，这就是装饰模式所想达到的目的

装饰后的对象，依然是同一种对象，因此可以非常自由的反复装饰，同时原本适用的接口或者方案，装饰之后依然能够使用

比如，“我是一个人”，加上装饰“我是一个正直善良聪明可爱但也许并不算帅气的男生”，但是说到底我仍然是个人，我拥有一个人所拥有的思考和行为方式

作者：Echo_Ye

WX：Echo_YeZ

Email ：[email protected]

个人站点：在搭了在搭了。。。（右键 - 新建文件夹）