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

对于初识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实现为例：

Java代码  

1. public class PCRenderServcie extends RenderService{  
2.     private boolean isCdn;  
3.     private boolean isRedis;  
4.     private boolean isGetSku;  
5.     public void render(){  
6.         System.out.println("完成pc基础页面渲染");  
7.         if(isCdn){  
8.             cdnHandle();  
9.             System.out.println("cdn缓存处理");  
10.         }  
11.    
12.         if(isRedis){  
13.             redisHandle();  
14.             System.out.println("redis缓存处理");  
15.         }  
16.    
17.         if(isGetSku){  
18.             skuHandle();  
19.             System.out.println("抓取页面上的sku");  
20.         }  
21.     }  
22.      
23.     //省略getter setter方法  
24. }  

 

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

 

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

 

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

 

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

 

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

 

抽象的接口 角色

 

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

Java代码  

1. public interface RenderService {  
2.     void render();  
3. }  
4.    

 

具体的被装饰者 角色

 

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

Java代码  

1. public class PcRenderService implements RenderService{  
2. public void render() {  
3.     //省略渲染过程  
4.         System.out.println("pc页面渲染");  
5.     }  
6. }  
7.    
8. public class MRenderServcie implements RenderService{  
9. public void render() {  
10.     //省略渲染过程  
11.         System.out.println("m页面渲染");  
12.     }  
13.    
14. }  
15.    

 

抽象的装饰者 角色

 

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

 

Java代码  

1. public abstract class AbstractDecorator implements RenderService{  
2.     protected RenderService renderService; //“具体的被装饰者”也是RenderService类型  
3.    
4.     protected AbstractDecorator(RenderService renderService){  
5.         this.renderService=renderService;  
6.     }  
7. }  
8.    

 

具体的装饰者 角色

 

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

 

Java代码  

1. //redis缓存装饰器  
2. public class CacheDecorator extends AbstractDecorator {  
3.    
4.     public CacheDecorator(RenderService renderService){  
5.         super(renderService);  
6.     }  
7.    
8.     public void render() {  
9.         renderService.render();  
10.         redisHandle();  
11.     }  
12.    
13.     private void redisHandle(){  
14.         System.out.println("渲染完成后缓存到redis");  
15.     }  
16. }  
17.    
18. public class CdnDecorator extends AbstractDecorator {  
19. //cdn缓存装饰器  
20.     public CdnDecorator(RenderService renderService){  
21.         super(renderService);  
22.     }  
23.    
24.     public void render() {  
25.         renderService.render();  
26.         cdnHandle();  
27.     }  
28.    
29.     private void cdnHandle(){  
30.         System.out.println("渲染完成后推送cdn");  
31.     }  
32. }  
33.    
34. //页面sku抓取装饰器  
35. public class GetSkuDecorator extends AbstractDecorator {  
36.    
37.     public GetSkuDecorator(RenderService renderService){  
38.         super(renderService);  
39.     }  
40.    
41.     public void render() {  
42.         renderService.render();  
43.         getSku();  
44.     }  
45.    
46.     private void getSku(){  
47.         System.out.println("渲染完成后抓取页面sku");  
48.     }  
49. }  
50.    

 

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

 

Java代码  

1. public class Main {  
2.     public static void main(String[] args) {  
3.    
4.         //渲染一个 redis缓存+cdn缓存+sku抓取的 m页面  
5.         RenderService mRenderServcie = new MRenderServcie();  
6.         mRenderServcie = new CacheDecorator(mRenderServcie);  
7.         mRenderServcie = new GetSkuDecorator(mRenderServcie);  
8.         mRenderServcie = new CdnDecorator(mRenderServcie);  
9.         mRenderServcie.render();  
10.         System.out.println("        ");  
11.    
12.         //渲染一个 redis缓存+cdn缓存 pc页面  
13.         RenderService pcRenderServcie = new PcRenderService();  
14.         pcRenderServcie = new CacheDecorator(pcRenderServcie);  
15.         pcRenderServcie = new CdnDecorator(pcRenderServcie);  
16.         pcRenderServcie.render();  
17.     }  
18. }  
19.    

 

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

Java代码  

1. m页面渲染  
2. 渲染完成后缓存到redis  
3. 渲染完成后抓取页面sku  
4. 渲染完成后推送cdn  
5.          
6. pc页面渲染  
7. 渲染完成后缓存到redis  
8. 渲染完成后推送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包），但如果你已经熟悉了“装饰器模式”，那就不是问题了。

 

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