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

概述

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

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

---

Java IO 类的 “奇怪” 用法

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

	字节流	字符流
输入流	InputStream	Reader
输出流	OutputStream	Writer

针对不同的读取和写入场景，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) {
	//...
}

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

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

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();

在这种情况下，如果继续按照继承的方式来实现的话，就需要再继续派生出 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;
	}    
	//...实现读取基本类型数据的接口...
}

看了上面的代码，你可能会问，那装饰器模式就是简单的 “用组合替代继承” 吗？当然不是。从 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();

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

// 代理模式的代码结构（下面的接口也可以替换成抽象类）
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();
        // 功能增强代码
    }
}

实际上，如果查看 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();
	}
}

实际上，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();
    }
}

总结

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