设计模式之装饰者模式

标题装饰者在JDK中的应用

java.io.InputStream、 Output­Stream、 Reader 和 Writer 的所有代码都有以自身类型的对象作为参数的构造函数。

java.util.Collections； checked­XXX()、 synchronized­XXX() 和 unmodifiable­XXX() 方法。

javax.servlet.http.HttpServletRequestWrapper 和 Http­Servlet­Response­Wrapper

详细解析装饰者模式在io中的应用：

 
InputStream in = new FileInputStream("/hjw/test.txt");
InputStream buffer= new BufferedInputStream(in);
byte[] data = new byte[128];
while (buffer.read(data) != -1) {
  //...
}

    初看上面的代码，我们会觉得 Java IO 的用法比较麻烦，需要先创建一个 FileInputStream 对象，然后再传递给 BufferedInputStream 对象来使用。那么Java IO 为什么不设计一个继承 FileInputStream 并且支持缓存的 BufferedFileInputStream 类呢？这样我们就可以像下面的代码中这样，直接创建一个 BufferedFileInputStream 类对象，打开文件读取数据，用起来岂不是更加简单？

   如果 InputStream 只有一个子类 FileInputStream 的话，那我们在 FileInputStream 基础之上，再设计一个孙子类 BufferedFileInputStream，也算是可以接受的，毕竟继承结构还算简单。但实际上，继承 InputStream 的子类有很多。我们需要给每一个 InputStream 的子类，再继续派生支持缓存读取的子类。除了支持缓存读取之外，如果我们还需要对功能进行其他方面的增强，比如下面的 DataInputStream 类，支持按照基本数据类型（int、boolean、long 等）来读取数据。

   在这种情况下，如果我们继续按照继承的方式来实现的话，就需要再继续派生出 DataFileInputStream、DataPipedInputStream 等类。如果我们还需要既支持缓存、又支持按照基本类型读取数据的类，那就要再继续派生出 BufferedDataFileInputStream、BufferedDataPipedInputStream 等 n 多类。这还只是附加了两个增强功能，如果我们需要附加更多的增强功能，那就会导致组合爆炸，类继承结构变得无比复杂，代码既不好扩展，也不好维护。

  IO基于装饰者模式的设计方案:

 
public abstract class InputStream {
  //...
  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("/hjw/test.txt");
InputStream buffer= new BufferedInputStream(in);
DataInputStream din = new DataInputStream(buffer);
int data = din.readInt();

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

    实际上，如果去查看 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()
  public void f() {
    in.f();
  }  
}

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

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

Java的IO结构，FilterInputStream就是一个装饰者

public abstract class InputStream implements Closeable{} //是一个抽象类，即Component   
public class FilterInputStream extends InputStream { //是一个装饰者类Decorator      
    protected volatile InputStream in//被装饰的对象 }
 
class DataInputStream extends FilterInputStream implements DataInput {//FilterInputStream 子类，也继承了被装饰的对象}

public class Decorator {
 
	public static void main(String[] args) throws Exception{
	
		//说明
		//1. InputStream 是抽象类
		//2. FileInputStream 是  InputStream 子类
		//3. FilterInputStream  是  InputStream 子类
		//4. DataInputStream 是 FilterInputStream 子类，具体的修饰者
		//5. FilterInputStream 类 有  protected volatile InputStream in; 即含被装饰者
		//6. 分析得出在jdk 的io体系中，就是使用装饰者模式
		
		DataInputStream dis = new DataInputStream(new FileInputStream("d:\\abc.txt"));
		System.out.println(dis.read());
		dis.close();
	}
 
}

装饰模式适合应用场景
如果你希望在无需修改代码的情况下即可使用对象， 且希望在运行时为对象新增额外的行为， 可以使用装饰模式。
装饰能将业务逻辑组织为层次结构， 可为各层创建一个装饰， 在运行时将各种不同逻辑组合成对象。 由于这些对象都遵循通用接口， 客户端代码能以相同的方式使用这些对象。

如果用继承来扩展对象行为的方案难以实现或者根本不可行， 你可以使用该模式。
许多编程语言使用 final最终关键字来限制对某个类的进一步扩展。 复用最终类已有行为的唯一方法是使用装饰模式： 用封装器对其进行封装。

五、装饰模式优缺点
无需创建新子类即可扩展对象的行为。
可以在运行时添加或删除对象的功能。
可以用多个装饰封装对象来组合几种行为。
单一职责原则。 可以将实现了许多不同行为的一个大类拆分为多个较小的类。
XXX 在封装器栈中删除特定封装器比较困难。
XXX实现行为不受装饰栈顺序影响的装饰比较困难。
XXX各层的初始化配置代码看上去可能会很糟糕。
六、与其他模式的关系
适配器模式可以对已有对象的接口进行修改， 装饰模式则能在不改变对象接口的前提下强化对象功能。 此外， 装饰还支持递归组合， 适配器则无法实现。

适配器能为被封装对象提供不同的接口， 代理模式能为对象提供相同的接口， 装饰则能为对象提供加强的接口。

责任链模式和装饰模式的类结构非常相似。 两者都依赖递归组合将需要执行的操作传递给一系列对象。 但是， 两者有几点重要的不同之处。

责任链的管理者可以相互独立地执行一切操作， 还可以随时停止传递请求。 另一方面， 各种装饰可以在遵循基本接口的情况下扩展对象的行为。 此外， 装饰无法中断请求的传递。

组合模式和装饰的结构图很相似， 因为两者都依赖递归组合来组织无限数量的对象。

装饰类似于组合， 但其只有一个子组件。 此外还有一个明显不同： 装饰为被封装对象添加了额外的职责， 组合仅对其子节点的结果进行了 “求和”。

但是， 模式也可以相互合作： 你可以使用装饰来扩展组合树中特定对象的行为。

大量使用组合和装饰的设计通常可从对于原型模式的使用中获益。 你可以通过该模式来复制复杂结构， 而非从零开始重新构造。

装饰可让你更改对象的外表， 策略模式则让你能够改变其本质。

装饰和代理有着相似的结构， 但是其意图却非常不同。 这两个模式的构建都基于组合原则， 也就是说一个对象应该将部分工作委派给另一个对象。 两者之间的不同之处在于代理通常自行管理其服务对象的生命周期， 而装饰的生成则总是由客户端进行控制。