设计模式学习笔记 - 设计模式与范式 -结构型：3.装饰器模式

概述

上篇文章《设计模式与范式 -结构型：2.桥接模式》，我们介绍了桥接模式，桥接模式的理解方式有两种。第一种理解方式是 “将抽象与实现解耦，让它们能独立开发”。这种理解方式比较特别，应用场景也不多。另一种理解方式更加简单，类似 “组合优于继承” 设计原则，这种理解方式更加通用，应用场景比较多。不管理哪种理解方式，它们的代码结构都是相同的，都是一种类之间的组合关系。

本章，通过剖析 Java IO 类的设计思想，再学习一种新的结构型模式，装饰器模式。它的代码结构跟桥接模式非常相似，不过解决的问题却大不相同。

---

Java IO 类的 “奇怪” 用法

Java IO 类库非常庞大复杂，有几十个类，负责 IO 数据的读取和写入。如果对 Java IO 类一下分类，可以从下面两个维度将它划分为四类。

针对不同的读取和写入场景，Java IO 又在这四个父类的基础上，扩展出了很多子类。具体如下所示：

在初学 Java 的时候，曾对 Java IO 的一些用法产生过很大的怀疑，比如下面这段代码。我们打开 test.txt，从中读取数据。其中，InputStream 是一个抽象类，FileInputStream 是专门用来读取文件流的子类。BufferedInputStream 是一个支持待缓存功能的数据读取类，可以提高读取的效率。

InputStream in = new FileInputStream("/test.txt");
InputStream bin = new BufferedInputStream(in);
byte[] data = new byte[128];
while(bin.read(data) != -1) {
	//...
}
1
2
3
4
5
6

初看上面的代码时，会觉得 Java IO 的用法太麻烦，需要先创建一个 FileInputStream 对象，然后再传递给 BufferedInputStream 对象来使用。Java IO 为什么不设计一个继承 FileInputStream 并且支持缓存功能的 BufferedFileInputStream 类呢？如果可以像下面这样使用的话，用起来岂不是会更加简便？

InputStream bin = new BufferedFileInputStream('/test.txt');
while(bin.read(data) != -1) {
	//...
}
1
2
3
4

I/0 基于继承的设计方案分析

如果 InputStream 只有一个子类 FileInputStream 的话，那我么在 FileInputStream 的基础上，再设计一个孙子类 BufferedFileInputStream 是可以接受的，毕竟继承结构还算简单。但实际上，继承 InputStream 的子类有很多。我们需要给每一个 InputStream 的子类，再继续派生支持缓存读取的子类。

除了支持缓存功能外，如果我们还需要对功能进行其他方面的增强，比如下面的 DataInputStream 类，支持按照基本数据类型（int、boolean、long 等）来读取数据。

InputStream in = new FileInputStream("/test.txt");
InputStream din = new DataInputStream(in);
int data = din.readInt();
1
2
3

在这种情况下，如果继续按照继承的方式来实现的话，就需要再继续派生出 DataFileInputStream、DataPipedInputStream 等类。如果我们还需既支持缓存、又支持按照基本类型读取数据的类，那就要再继续派生出 BufferedDataFileInputStream、BufferedDataPipedInputStream 等 n 多类。

这还只是附加了两个增强功能，如果还要继续附加更加夺的增强功能，那就会导致组合爆炸，类继承结构变得无比复杂，代码既不好扩展，也不好维护。这也是我们在《面向对象 - 7.为什么要多用组合少用继承？》中不推荐使用继承的原因。

I/0 基于装饰器模式的设计方案分析

在《面向对象 - 7.为什么要多用组合少用继承？》中，还讲到 “组合优于继承”，可以 “使用组合来替代继承”。针对刚刚的继承结构过于复杂的问题，可以通过组合关系来解决。下面的代码展示了 Java IO 的这种设计思路。下面的代码做了简化，只抽象出必要的代码，感兴趣的同学可以直接去查看 JDK 源码。

public abstract class InputStream implements Closeable {
	// ...
	public abstract int read() throws IOException;
	
    public int read(byte b[]) throws IOException {
        return read(b, 0, b.length);
    }

    public int read(byte b[], int off, int len) throws IOException {
        // ...
    }

    public long skip(long n) throws IOException {
		// ...
    }

    public int available() throws IOException {
        return 0;
    }

    public void close() throws IOException {}

    public synchronized void mark(int readlimit) {}

    public synchronized void reset() throws IOException {
        throw new IOException("mark/reset not supported");
    }

    public boolean markSupported() {
        return false;
    }
}

public class BufferedInputStream extends InputStream {
	protected volatile InputStream in;
	protected BufferedInputStream(InputStream in) {
		this.in = in;
	}    
	//...实现基于缓存的读数据接口...
}

public class DataInputStream extends InputStream {
	protected volatile InputStream in;
	protected DataInputStream(InputStream in) {
		this.in = in;
	}    
	//...实现读取基本类型数据的接口...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

看了上面的代码，你可能会文，那装饰器模式就是简单的 “用组合替代继承” 吗？当然不是。从 Java IO 的设计上来看，装饰器模式相对于简单的组合关系，还有两个比较特殊的地方。

第一个比较特殊的地方：装饰器类和原始类继承同样的父类，这样我们就可以对原始类 “嵌套” 多个装饰器类。比如，下面的代码对 FileInputStream 嵌套了两个装饰器类：BufferedInputStream 和 DataInputStream ，让它及支持缓存读取，又支持按照基本数据类型来读取数据。

InputStream in = new FileInputStream('/test.txt');
InputStream bin = new BufferedInputStream(in);
InputStream din = new DataInputStream(bin);
int data = din.readInt();
1
2
3
4

第二个比较特殊的地方：装饰器类是对功能的增强，这也是装饰器模式应用场景的一个重要特点。实际上，符合 “组合关系” 这种代码结构的设计模式有很多，比如之前讲过的代理模式、桥接模式，还有现在的装饰器模式。尽管它们的代码结构很相似，但是每周设计模式的意图不同。就拿比较相似的代理模式和桥接模式来说吧，代理模式中，代理类附加的是和原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。

// 代理模式的代码结构（下面的接口也可以替换成抽象类）
public interface IA {
    void f();
}
public class A implements IA {
    @Override
    public void f() {/*...*/}
}
public class AProxy implements IA {
    private A a;
    public AProxy(A a) {
        this.a = a;
    }
    @Override
    public void f() {
        // 添加新的代理逻辑
        a.f();
        // 添加新的代理逻辑
    }
}

// 适配器模式的代码结构（下面的接口也可以替换成抽象类）
public interface IA {
    void f();
}
public class A implements IA {
    @Override
    public void f() {/*...*/}
}
public class ADecorator implements IA {
    private A a;
    public ADecorator(A a) {
        this.a = a;
    }

    @Override
    public void f() {
        // 功能增强代码
        a.f();
        // 功能增强代码
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

实际上，如果查看 JDK 源码，你会发现， BufferedInputStream 和 DataInputStream 并非继承 InputStream，而是另外一个叫 FilterInputStream 的类。这又是出于什么样的设计意图呢？

再看下 BufferedInputStream 的代码。InputStream 是一个抽象类而非接口，而且它的大部分函数（比如 read()、available()）都有默认实现，按理来说，只需要在 BufferedInputStream 类中重新实现那些需要增加缓存功能的函数就可以了，其他函数继承 InputStream 的默认实现。实际上，这样做是行不通的。

对于即便是不需要增加缓存功能的函数来说，BufferedInputStream 还是必须把它重新实现一遍，简单包裹对 InputStream 对象的调用。具体的代码如下所示。如果不重新实现一遍，那 BufferedInputStream 类就无法将最终操作数据的任务，委托给传递进来的 InputStream 对象来完成。这部分可能稍微有点绕，你自己多思考一下。

public class BufferedInputStream extends InputStream {
	protected volatile InputStream in;
	protected BufferedInputStream(InputStream in) {
		this.in = in;
	}
	
	// f()函数不需要增强，知识重新调用一下 InputStream in 对象的 f()
	@Override
	public void f() {
		in.f();
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

实际上，DataInputStream 也存在跟 BufferedInputStream 同样的问题。为了避免重复代码，Java IO 抽象出了一个装饰器父类 FilterInputStream ，代码实现如下。InputStream 的所有装饰器类都继承自这个装饰器父类。这样，装饰器类只需要实现它需要增强的方法就可以了，其他方法继承装饰器父类的默认实现。

public class FilterInputStream extends InputStream {
    protected volatile InputStream in;
    protected FilterInputStream(InputStream in) {
        this.in = in;
    }
    
    public int read() throws IOException {
        return in.read();
    }

    public int read(byte b[]) throws IOException {
        return read(b, 0, b.length);
    }

    public int read(byte b[], int off, int len) throws IOException {
        return in.read(b, off, len);
    }

    public long skip(long n) throws IOException {
        return in.skip(n);
    }

    public int available() throws IOException {
        return in.available();
    }

    public void close() throws IOException {
        in.close();
    }

    public synchronized void mark(int readlimit) {
        in.mark(readlimit);
    }
    
    public synchronized void reset() throws IOException {
        in.reset();
    }

    public boolean markSupported() {
        return in.markSupported();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

总结

装饰器模式主要解决继承关系过于复杂的问题，通过组合来代替继承。它主要的作用是给原始类添加增强功能。这也是判断是否该用装饰器模式的重要依据。此外，装饰器模式还有一个特点，那就是可以对原始类嵌套使用多个装饰器。为了满足这个应用场景，在设计的时候，装饰器类需要跟原始类继承相同的抽象类和接口。