装饰器模式(Decorator Pattern)该如何使用在项目？-技术圈

点击上方“JavaEdge”，关注公众号

设为“星标”，好文章不错过！

在实际开发中，一般你会如何给一个类或对象新增行为呢？

继承

子类在拥有自身方法的同时还拥有父类方法。但这种方案是比较静态的，用户无法控制新增行为的方式和时机。

关联

将一个类的对象A嵌入另一个对象B，由另一个对象决定是否调用嵌入对象B的行为以便扩展自身行为，这个嵌入的对象B就叫做装饰器(Decorator)。

定义

对象结构型模式。动态地给一个对象增加额外功能，装饰器模式比生成子类实现更为灵活。

角色

Component 接口

抽象构件，定义了对象的接口，可以给这些对象动态增加功能。

ConcreteComponent

具体构件，定义了具体的构件对象，实现了在抽象构件中声明的方法，装饰器可以给它增加额外职责（方法）。

Decorator

抽象装饰类，是抽象构件类的子类，用于给具体构件增加职责，但具体职责实现在其子类。

ConcreteDecorator

具体装饰类，是抽象装饰类的子类，负责向构件添加新的职责。

代码案例

窗口接口

public interface Window {
  // 绘制窗口  public void draw();    // 返回窗口的描述  public String getDescription();}

无滚动条功能的简单窗口实现

public class SimpleWindow implements Window {
  public void draw() {    // 绘制窗口  }
  public String getDescription() {    return "simple window";  }}

抽象装饰类，注意实现Window接口

public abstract class WindowDecorator implements Window {    // 被装饰的Window    protected Window decoratedWindow;
    public WindowDecorator (Window decoratedWindow) {        this.decoratedWindow = decoratedWindow;    }        @Override    public void draw() {        decoratedWindow.draw();    }
    @Override    public String getDescription() {        return decoratedWindow.getDescription();    }}

第一个具体装饰器，添加垂直滚动条功能

public class VerticalScrollBar extends WindowDecorator {  public VerticalScrollBar(Window windowToBeDecorated) {    super(windowToBeDecorated);  }
  @Override  public void draw() {    super.draw();    drawVerticalScrollBar();  }
  private void drawVerticalScrollBar() {    // Draw the vertical scrollbar  }
  @Override  public String getDescription() {    return super.getDescription() + ", including vertical scrollbars";  }}

第二个具体装饰器，添加水平滚动条功能

public class HorizontalScrollBar extends WindowDecorator {  public HorizontalScrollBar (Window windowToBeDecorated) {    super(windowToBeDecorated);  }
  @Override  public void draw() {    super.draw();    drawHorizontalScrollBar();  }
  private void drawHorizontalScrollBar() {    // Draw the horizontal scrollbar  }
  @Override  public String getDescription() {    return super.getDescription() + ", including horizontal scrollbars";  }}

优点

装饰模式以对用户透明的方式动态给一个对象附加功能，用户不会觉得对象在装饰前、后有何不同。装饰模式可在无需创造更多子类情况下，扩展对象的功能。

与继承相比，关联优势在于不破坏类的封装性，而且继承是一种耦合度较大的静态关系，无法在程序运行时动态扩展。

可通过动态方式扩展一个对象的功能，通过配置文件可以在运行时选择不同装饰器，从而实现不同行为。

在软件开发阶段，关联关系虽然不会比继承关系减少编码量，但到了软件维护阶段，由于关联关系使系统具有较好的松耦合性，所以更容易维护。

通过使用不同具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合。可以使用多个具体装饰类来装饰同一对象，得到功能更强大的对象。

具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类、具体装饰类，在使用时再对其进行组合，原有代码无须改变，符合“开闭原则”。

缺点

产生很多小对象，这些对象区别在于它们之间相互连接的方式不同，而非类或属性值不同，同时还将产生很多具体装饰类。这些装饰类和小对象的产生将增加系统的复杂度，加大学习与理解的难度。

比继承更灵活，也意味着比继承更易出错，排查也更困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为烦琐。

适用场景

在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责
需要动态地给一个对象增加功能，这些功能也可以动态地被撤销
当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时

不能采用继承的场景：

系统存在大量独立扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长
类定义不能继承（如final类）

扩展

一个装饰类的接口必须与被装饰类的接口保持相同，对于客户端来说无论是装饰之前的对象还是装饰之后的对象都可以一致对待。
尽量保持具体构件类的轻量，也就是说不要把太多的逻辑和状态放在具体构件类中，可以通过装饰类对其进行扩展。

装饰模式可分为：

透明装饰模式
要求客户端完全针对抽象编程，装饰模式的透明性要求客户端程序不应该声明具体构件类型和具体装饰类型，而应该全部声明为抽象构件类型。
半透明装饰模式
允许用户在客户端声明具体装饰者类型的对象，调用在具体装饰者中新增的方法。

往期推荐

拥抱Kubernetes,再见了Spring Cloud

百度二面:一个线程OOM了,其它线程还能运行吗?

这一次彻底搞懂JDK动态代理

Iterator迭代器到底是什么?

目前交流群已有 800+人，旨在促进技术交流，可关注公众号添加笔者微信邀请进群

喜欢文章，点个“在看、点赞、分享”素质三连支持一下~