设计模式详解——装饰者模式

前言

在程序开发设计中，有一个特别重要的原则是，类应该对扩展开放，对修改关闭，虽然这一原则听起来很矛盾，但是在一些比较优秀的设计模式中，是完全可以达成这一原则的，比如装饰者模式，它就是这一原则的最佳实践，下面我们来看下它的基本原理和用法，希望能通过这篇内容，引发给位小伙伴对于设计模式的思考。

装饰者模式

装饰者模式动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性地替代方案。

要点

继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式；
在我们的设计中，应该允许行为可以被扩展，而无须修改现有代码
组合和委托可用于在运行时动态地加上新的行为
除了继承，装饰者模式也可以让我们扩展行为
装饰者模式意味着一群装饰者类，这些类用来包装具体组件
装饰者类反映出被装饰组件地类型（他们具有相同的类型，都经过接口或继承实现）
装饰者可以在被装饰者地行为前面或者后面加上自己的行为，甚至将被装饰者的行为整体覆盖，从而达到特定目的
装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型
装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得复杂。

示例代码

原始对象接口

基类接口，也是包装类最底层的内容（俄罗斯套娃里面第一个被套的那个），也可以理解为包装类中的最小单位，这里我们用形状这个抽象概念作为示例演示。

首先这个抽象接口有一个基本方法，就是draw绘制方法，凡是实现了形状这个接口的所有类都必须实现这个接口。

public interface Shape {
    /**
     * 绘制方法
     */
    void draw();
}

接口实现

这里是接口的实现，不过为了方便理解，各位小伙伴可以把接口的实现当作第一层包装类，这一层包装相当于直接确定了我们形状的基本属性，表明它是一个圆形。

public class Circle implements Shape {
    @Override
    public void draw() {
        System.out.println("绘制圆形");
    }
}

同理，这里确定了我们的形状为矩形。

public class Rectangle implements Shape {
    @Override
    public void draw() {
        System.out.println("绘制矩形");
    }
}

装饰对象抽象

这里相当于做一个通用的包装接口，后续的包装类只需要继承这个抽象类，然后再在其中加入新的行为或属性即可，而不需要重复封装。

public abstract class ShapeDecorator implements Shape {
    protected Shape decoratedShape;

    public ShapeDecorator(Shape decoratedShape){
        this.decoratedShape = decoratedShape;
    }

    public void draw(){
        decoratedShape.draw();
    }
}

装饰者实现

这里就是第一层包装（如果按我们上面的说法应该是第三层，因为我们传递的肯定是shape的实现，而不是抽象接口），这里继承了上面的抽象包装类。

public class RedShapeDecorator extends ShapeDecorator {

    public RedShapeDecorator(Shape decoratedShape) {
        super(decoratedShape);
    }

    @Override
    public void draw() {
        decoratedShape.draw();
        setRedBorder(decoratedShape);
    }

    private void setRedBorder(Shape decoratedShape){
        System.out.println("Border Color: Red");
    }
}

同时引入了一个新的方法setRedBorder，这个方法让我们的形状有了一个新的属性——红色。当然，我们还可以继续封装，我们可以在颜色的基础上给他封装一个尺寸：

public class SizeShapeDecorator extends RedShapeDecorator{

    public SizeShapeDecorator(Shape decoratedShape) {
        super(decoratedShape);
    }

    @Override
    public void draw() {
        super.draw();
        setSize(decoratedShape);
    }

    private void setSize(Shape decoratedShape) {
        System.out.println("size: 100");
    }
}

测试代码

这里我们分别创建一个圆形和矩形，指定不同的包装类，并调用他们的draw方法：

	@Test
    public void testDecorator() {
        Shape circle = new Circle();
        ShapeDecorator redCircle = new RedShapeDecorator(new Circle());
        ShapeDecorator redRectangle = new RedShapeDecorator(new Rectangle());
        ShapeDecorator sizeRedRectangle = new SizeShapeDecorator(new Rectangle());
        System.out.println("原始圆形");
        circle.draw();

        System.out.println("===========\n包装的红色圆形");
        redCircle.draw();

        System.out.println("===========\n包装的红色矩形");
        redRectangle.draw(); 
        
        System.out.println("===========\n包装的100红色矩形");
        sizeRedRectangle.draw();
    }

最后运行结果如下：

总结

从示例代码及运行结果我们可以看出来，虽然后续我们不断为原始的形状加入了新的属性，但是我们并没有改变原始代码，而是一层一层地添加不同的包装类，然后让它逐步有了更多的新属性。

这样的操作好处是，我们原有的形状拥有了新的属性，但这些后增加的属性和原始形状之间并没有任何强依赖关系，也没有破坏原因业务逻辑，保证了系统的可扩展性，同时耦合性还很低，这就是装饰者设计模式的魅力。

不知道各位小伙伴是否还记得我们前段时间分享的spring boot源码相关内容，spring boot的源码中就用到了装饰者模式，比如BeanFactory的相关内容，另外我们日常开发过程中用到的Tomcat有好多地方也用到了这种设计模式，最典型的是ServletRequest和ServletResponse。