装饰器模式--继承的另一种选择

java.io包的困惑

 

对于初识java的程序员来说，甚至已经工作三五年的java老鸟们，对java.io包中各种“流”以及五花八门的api都是浑浑噩噩搞不清（笔者在刚接触java时也经历过同样的迷茫）。但如果你已经熟悉了“装饰器模式”的话，再来看一遍java.io中API，就会有一种豁然开朗的感觉。

 

继承是实现类复用的重要手段，但却不是唯一的手段，通过类的关联组合同样可以做到，而且如果使用得当 比通过继承更富有弹性。“装饰器模式”就是通过组合来实现类似复用和包装，这就是OO设计的另一个原则“合成复用原则”：则是尽量使用合成/聚合的方式，而不是使用继承。

 

在讲解java.io包之前，先来熟悉下“装饰器模式”。

 

装饰器模式

 

装饰器模式可以动态的把新的职责添加到对象上，在扩展性方面比通过继承实现扩展更富有弹性。这里关键点是“动态”，也就是运行时；而继承在编译的时候已经确定了。先来看下类图：

 

 

从类图中可以看到该模式有4类角色：

其中 Component是抽象的接口；ConcreteComponent0、ConcreteComponent1是具体的实现 也就是具体被装饰者；Decorator是抽象的装饰者可以是接口或抽象类，它跟“被装饰者”处在同一层级上；ConcreteDecoratorA、ConcreteDecoratorB、ConcreteDecoratorC具体的装饰者在同 他们的主要作用就是对“具体的被装饰者”进行包装，附件新的功能。

 

该模式的核心就是，抽象的装饰者Decorator，它起到承上启下的作用：继承(或实现) Component，使得所有的“装饰器”和“被装饰器”类型相同（实现针对接口编程）；同时Decorator中定义了一个Component类型的成员变量，指向“具体的被装饰者”，通过“组合”的方式实现对其进行包装。

 

也许你会说这里Decorator是继承自Component，也用到了“继承”。但这里继承的作用仅仅是为了跟“具体的被装饰者”类型保持相同，主要还是通过组合的方式（即成员变量）对component成员进行包装。

 

“具体的装饰器”不仅可以包装“具体的被装饰者”，它还可以多层嵌套包装“具体的装饰器”（最内层必须是“具体的被装饰者”），从而实现动态的多个附加功能的添加。

 

示例展示

 

本示例场景是做web开发中都会遇到的页面渲染场景：业务需求是要渲染PC页面（电脑版页面）、M页面（移动端页面）；同时针对不同的页面需要 缓存到redis、缓存cdn、抓取页面上的sku。这时就产生了一系列的组合，PC页面+reddis缓存+抓取sku、PC页面+redis缓存、M页面、M页面+redis缓存 等等一系列的组合。解决办法有三种：

 

方式一：继承，如果为每个类型创建新的子类，势必会产生一些列的子类，而且毫无复用性可言。直接放弃。

 

方式二：继承，当然也许你会想到另外一种解决方式：只创建 PC页面、M页面渲染类，把 reddis缓存、cdn缓存、sku抓取作为单独的方法，再进行一些列的判断 来实现复用：

 

 

这里以及PCRenderServcie实现为例：

public class PCRenderServcie extends RenderService{
    private boolean isCdn;
    private boolean isRedis;
    private boolean isGetSku;
    public void render(){
        System.out.println("完成pc基础页面渲染");
        if(isCdn){
            cdnHandle();
            System.out.println("cdn缓存处理");
        }
 
        if(isRedis){
            redisHandle();
            System.out.println("redis缓存处理");
        }
 
        if(isGetSku){
            skuHandle();
            System.out.println("抓取页面上的sku");
        }
    }
   
    //省略getter setter方法
}

 

这里把RenderService设计成抽象类，并把这些方法cdnHandle()、redisHandle()、skuHandle()公共方法提取到RenderService中，MRenderServcie的实现与上述PCRenderServcie类似 可以共用这些方法。

 

这种方式从一定程度上 实现了部分代码复用，并且解决方式一中的“子类泛滥”的问题。但缺点也很明显，假设现在要新增一个操作，所有RenderService、PCRenderServcie、MRenderServcie都会涉及到修改。无法满足“开闭原则”，对以前的代码造成破坏。

 

前面两种方式都是尝试使用“继承”来解决问题，我们可以看到效果都不是很理想。下面来看看今天的主角“装饰器模式”，是如何解决上述问题的。

 

方式三：装饰器模式，采用装饰器模式，我们首先要区分出业务场景中 那些是“被装饰者”，哪些是“装饰者”。从方式二中 其实就可以区分开来：PCRenderServcie和MRenderServcie是基础操作 可以被看做是“被装饰者”；是否cdn缓存、是否redis缓存、是否抓取sku，这些动作可以看做是“可有可无”的“装饰者”，用来增强“被装饰者”的基础操作。

 

区分出“被装饰者”和“装饰者”后，就可以开始实现了，按照类图的4个角色 分别来实现：

 

抽象的接口 角色

 

首先来看“抽象的接口”，本实例中该接口中只定义了一个render方法：

public interface RenderService {
    void render();
}
 

 

具体的被装饰者 角色

 

具体的被装饰者角色有两个：PcRenderServcie 、MRenderServcie，实现了pc和m页面渲染的基础操作逻辑：

public class PcRenderService implements RenderService{
public void render() {
    //省略渲染过程
        System.out.println("pc页面渲染");
    }
}
 
public class MRenderServcie implements RenderService{
public void render() {
    //省略渲染过程
        System.out.println("m页面渲染");
    }
 
}
 

 

抽象的装饰者 角色

 

根据上述类图介绍，抽象的装饰者需要继承“抽象的接口”RenderService，并且拥有一个“具体的被装饰者”成员变量：

 

public abstract class AbstractDecorator implements RenderService{
    protected RenderService renderService; //“具体的被装饰者”也是RenderService类型
 
    protected AbstractDecorator(RenderService renderService){
        this.renderService=renderService;
    }
}
 

 

具体的装饰者 角色

 

本示例中有三个具体的装饰者：CacheDecorator(增加redis缓存处理)、CdnDecorator(增加cdn缓存处理)、GetSkuDecorator(增加sku抓取处理)。可以看到装饰者角色的作用 其实就是对被装饰者进行增强，并且可以在运行期选择性的增强。下面分别来看看具体的实现：

 

//redis缓存装饰器
public class CacheDecorator extends AbstractDecorator {
 
    public CacheDecorator(RenderService renderService){
        super(renderService);
    }
 
    public void render() {
        renderService.render();
        redisHandle();
    }
 
    private void redisHandle(){
        System.out.println("渲染完成后缓存到redis");
    }
}
 
public class CdnDecorator extends AbstractDecorator {
//cdn缓存装饰器
    public CdnDecorator(RenderService renderService){
        super(renderService);
    }
 
    public void render() {
        renderService.render();
        cdnHandle();
    }
 
    private void cdnHandle(){
        System.out.println("渲染完成后推送cdn");
    }
}
 
//页面sku抓取装饰器
public class GetSkuDecorator extends AbstractDecorator {
 
    public GetSkuDecorator(RenderService renderService){
        super(renderService);
    }
 
    public void render() {
        renderService.render();
        getSku();
    }
 
    private void getSku(){
        System.out.println("渲染完成后抓取页面sku");
    }
}
 

 

到这里“装饰器模式”的4个角色都已实现完毕，下面来进行测试，测试内容为（其实可以任意的组合）：首先创建一个带redis缓存+cdn缓存+页面sku抓取的“m页面”；再创建一个带redis缓存+cdn缓存的“pc页面”。测试代码：

 

public class Main {
    public static void main(String[] args) {
 
        //渲染一个 redis缓存+cdn缓存+sku抓取的 m页面
        RenderService mRenderServcie = new MRenderServcie();
        mRenderServcie = new CacheDecorator(mRenderServcie);
        mRenderServcie = new GetSkuDecorator(mRenderServcie);
        mRenderServcie = new CdnDecorator(mRenderServcie);
        mRenderServcie.render();
        System.out.println("        ");
 
        //渲染一个 redis缓存+cdn缓存 pc页面
        RenderService pcRenderServcie = new PcRenderService();
        pcRenderServcie = new CacheDecorator(pcRenderServcie);
        pcRenderServcie = new CdnDecorator(pcRenderServcie);
        pcRenderServcie.render();
    }
}
 

 

运行上述main方法，执行结果如下：

m页面渲染
渲染完成后缓存到redis
渲染完成后抓取页面sku
渲染完成后推送cdn
       
pc页面渲染
渲染完成后缓存到redis
渲染完成后推送cdn

 

 

到这里，也许你已经看到“装饰器模式”的威力（如果还没看到，只能说明我没有讲好）。现在假设需要为pc页面添加头尾，只需要在加一个“头尾处理装饰器”即可，以前的代码完全不用做任何调整。如果需要再渲染一个“微信手Q”页面，只需要新增一个“被装饰者”，可以复用已有的三个“装饰者”进行任意组合的页面渲染。

 

java.io包

 

熟悉了“装饰器模式”，我们再回顾一下java的io包中的API。Java的io包中的api结构大致如下:

 

 

(注 本图来自百度图片，没有列全)

 

把上图分为三层：

第一层：Reader、Writer、InputStream、OutputStream，对应“抽象的接口”角色。

 

第二层：FilterOutputStream、FilterInputStream、FilterWriter、FilterReader这些带有Filter的类对应“抽象的装饰者”角色，这里也不一定要使用接口和抽象类，比如FilterOutputStream就是具体的实现类。这也属于“装饰器模式”。另外InputstreamReader也可以算“抽象的装饰者”，只是这里只对StreamDecoder类型进行装饰。

 

第二层其他：第二层中除了上述提到的5个类，其他的都可以看做是“具体的被装饰者”。

 

第三层：第三层都是“具体的装饰者” 比如：PrintStream、DateOutputStream、BufferInputSteam等。可以使用这些装饰器，对第二层中的类进行装饰。

 

如果把这个图顺时针旋转90度，你会发现它跟“装饰器模式”的类图很相似。

最后简单的看下，java.io流的用法：

public static void main(String[] args) throws Exception {

        InputStream inputStream = null;

        try{

 

            //使用第二层中的类 创建“被装饰者”

            inputStream = new FileInputStream("D://persion.txt");

 

            //使用第三层中的类 创建两个“具体的装饰者”

            inputStream = new BufferedInputStream(inputStream);//添加buffer读功能

            inputStream = new DataInputStream(inputStream);//添加读取基本java数据类型功能

 

            //开始读文件

            byte[] bs = new byte[inputStream.available()];

            inputStream.read(bs);

            String content = new String(bs);

            System.out.println(content);

        }finally{

            inputStream.close();

        }

    }

 

可以看到跟上述“装饰器模式”示例中的用法是一样的。想添加什么功能，就加什么装饰器进行包装即可。

 

小结

 

装饰器模式 可以在满足“开闭原则”的前提下，对“被装饰者”在运行时进行动态的包装（功能增强），是使用继承进行扩展的另一种选择。但由此也会产生很多“具体的装饰者”小类，让人困惑（比如 java的io包），但如果你已经熟悉了“装饰器模式”，那就不是问题了。

 

最后需要注意的是有些装饰器，是需要有序的进行包装的，这时最好把这部分独立出来进行复用（比如 可以使用工厂方法模式等），防止包装顺序出错。