JAVA IO 设计模式彻底分析

我想任何一本介绍模式的书在讲到Decorator模式的时候不能不提到它的实际应用－－在Java/IO库里面的应用，<< Java与模式>>这本书也不例外，有点不一样的是，这本书在介绍的时候有个专题，是从两个模式来看Java/IO库，完这个专题后，个人感 觉对Java/IO库有了全新的认识同时也加深了Decorator模式跟Adapter适配器模式的理解，现和大家分享下这个在我看来很伟大的成果，同 时说明下，以下大部分文字跟图片是来自<<Java与模式>>这本书。

　一.引子（概括地介绍Java的ＩＯ）

　无论是哪种编程语言，输入跟输出都是重要的一部分，Java也不例外，而且Java将输入／输出的功能和使用范畴做了很大的扩充。它 采用了流的机制来实现输入／输出，所谓流，就是数据的有序排列，而流可以是从某个源（称为流源或Source of Stream）出来，到某个目的地（称为流汇或Sink of Stream）去的。由流的方向，可以分成输入流和输出流，一个程序从输入流读取数据向输出流写数据。

　如，一个程序可以用FileInputStream类从一个磁盘文件读取数据，如下图所示：

　

　像FileInputStream这样的处理器叫做流处理器，它就像流的管道一样，从一个流源吸入某种类型的数据，并输出某种类型的数据。上面这种示意图叫做流的管道图。

　同样道理，也可以用FileOutputStream类向一个磁盘文件写数据，如下图所示：

　 　

　在实际应用这种机制并不没有太大的用处，程序需要写出地通常是非常结构化的信息，因此这些byte类型的数据实际上是一些数值，文 字，源代码等。Java的I/O库提供了一个称做链接（Chaining）的机制，可以将一个流处理器跟另一个流处理器首尾相接，以其中之一的输出为输 入，形成一个流管道的链接。

　例如，DataInputStream流处理器可以把FileInputStream流对象的输出当作输入，将Byte类型的数据转换成Java的原始类型和String类型的数据。如下图所示：

　类似地，向一个文件写入Byte类型的数据不是一个简单的过程。一个程序需要向一个文件里写入的数据往往都是结构化的，而Byte类 型则是原始类型。因此在写的时候必须经过转换。DataOutputStream流处理器提供了接收了原始数据类型和String数据类型，而这个流处理 器的输出数据则是Byte类型。也就是说DataOutputStream可以将源数据转换成Byte类型的数据，再输出来。

　这样一来，就可以将DataOutputStream与FileOutputStream链接起来，这样程序就可以将原始数据类型和String类型的源数据写入这个链接好的双重管道里面，达到将结构化数据写到磁盘文件里面的目的，如下图所示：

　

　这又是链接的所发挥的大作用。

　流处理器所处理的流必定都有流源，而如果将流类所处理的流源分类的话，基本可以分成两大类：

　第一　数组，String，File等，这一种叫原始流源。

　第二　同样类型的流用做链接流类的流源，叫链接流源。

　二　Java I/O库的设计原则

　Java语言的I/O库是对各种常见的流源，流汇以及处理过程的抽象化。客户端的Java程序不必知道最终的流源，流汇是磁盘上的文件还是数组等；也不必关心数据是否经过缓冲的，可否按照行号读取等处理的细节。

　书中提到了，对于第一次见到Java/IO库的人，无不因为这个库的庞杂而感到困惑；而对于熟悉这个库的人，而又常常为这个库的设计是否得当而争论不体。书的作者提出自己的意见，要理解Java I/O这个庞大而复杂的库，关键是要掌握两个对称性跟两个设计模式模式。

Java I/O库具有两个对称性，它们分别是：

　１　输入－输出对称性，比如InputStream和OutputStream各自占据Byte流的输入与输出的两个平行的等级结构的根部。而Reader和Writer各自占据Char流的输入与输出的两个平行的等级结构的根部。

　２　byte-char对称，InputStream和Reader的子类分别负责Byte和Char流的输入；OutputStream和Writer的子类分别负责Byte和Char流的输出，它们分别形成平行的等级结构。

Java I/O库的两个设计模式：

  Java的I/O库总体设计是符合装饰者模式（Decorator）跟适配器模式（Adapter）的。如前所述，这个库中处理流的类叫做流类。引子里所 谈到的FileInputStream，FileOutputStream，DataInputStream及DataOutputStream都是流处 理器的例子。

　１　装饰者模式：在由InputStream，OutputStream,Reader和Writer代表的等级结构内部，有一些流 处理器可以对另一些流处理器起到装饰作用，形成新的，具有改善了的功能的流处理器。装饰者模式是Java I/O库的整体设计模式。这样的一个原则是符合装饰者模式的，如下图所示：

２　适配器模式：在由InputStream，OutputStream,Reader和Writer代表的等级结构内部，有一些流处理器是对其它类型的流源的适配。这就是适配器模式的应用，如下图所示。

　　

　适配器模式应用到了原始流处理器的设计上面，构成了I/O库所有流处理器的起点。

　今天晚上先到这了，明天再接着细看两种设计模式具体是怎样在I/O库中被应用的。

 

 

JDK为程序员提供了大量的类库，而为了保持类库的可重用性，可扩展性和灵活性，其中使用到了大量的设计模式，本文将介绍JDK的I/O包中使用到的Decorator模式，并运用此模式，实现一个新的输出流类。

Decorator 模式简介
     Decorator模式又名包装器(Wrapper)，它的主要用途在于给一个对象动态的添加一些额外的职责。与生成子类相比，它更具有灵活性。
   有时候，我们需要为一个对象而不是整个类添加一些新的功能，比如，给一个文本区添加一个滚动条的功能。我们可以使用继承机制来实现这一功能，但是这种方法 不够灵活，我们无法控制文本区加滚动条的方式和时机。而且当文本区需要添加更多的功能时，比如边框等，需要创建新的类，而当需要组合使用这些功能时无疑将 会引起类的爆炸。
   我们可以使用一种更为灵活的方法，就是把文本区嵌入到滚动条中。而这个滚动条的类就相当于对文本区的一个 装饰。 这个装饰(滚动条)必须与被装饰的组件(文本区)继承自同一个接口，这样，用户就不必关心装饰的实现，因为这对他们来说是透明的。装饰会将用户的请求转发 给相应的组件(即调用相关的方法)，并可能在转发的前后做一些额外的动作(如添加滚动条)。通过这种方法，我们可以根据组合对文本区嵌套不同的装饰，从而 添加任意多的功能。这种动态的对对象添加功能的方法不会引起类的爆炸，也具有了更多的灵活性。
   以上的方法就是 Decorator 模式，它通过给对象添加装饰来动态的添加新的功能。如下是Decorator模式的UML图：

Component为组件和装饰的公共父类，它定义了子类必须实现的方法。
ConcreteComponent是一个具体的组件类，可以通过给它添加装饰来增加新的功能。
Decorator是所有装饰的公共父类，它定义了所有装饰必须实现的方法，同时，它还保存了一个对于Component的引用，以便将用户的请求转发给Component，并可能在转发请求前后执行一些附加的动作。
ConcreteDecoratorA和ConcreteDecoratorB是具体的装饰，可以使用它们来装饰具体的Component。

JAVA IO 包中的 Decorator 模式
   JDK提供的java.io包中使用了Decorator模式来实现对各种输入输出流的封装。以下将以java.io.OutputStream及其子类为例，讨论一下Decorator模式在IO中的使用。
   首先来看一段用来创建IO流的代码：

以下是代码片段： try {     OutputStream out = new DataOutputStream(new FileOutputStream("test.txt"));     } catch (FileNotFoundException e) {     e.printStackTrace();     }

 

这段代码对于使用过JAVA输入输出流的人来说再熟悉不过了，我们使用DataOutputStream封 装了一个FileOutputStream。这是一个典型的Decorator模式的使用，FileOutputStream相当于Component， DataOutputStream就是一个Decorator。将代码改成如下，将会更容易理解：

 

以下是代码片段： try {                 OutputStream out = new FileOutputStream("test.txt");                 out = new DataOutputStream(out);           } catch(FileNotFoundException e) {                 e.printStatckTrace();           }

 

由于FileOutputStream和DataOutputStream有公共的父类OutputStream，因此对对象的装饰对于用户来说几乎是透明的。下面就来看看OutputStream及其子类是如何构成Decorator模式的：

OutputStream是一个抽象类，它是所有输出流的公共父类，其源代码如下：

以下是代码片段： public abstract class OutputStream implements Closeable, Flushable {          public abstract void write(int b) throws IOException;          ...  }

它定义了write(int b)的抽象方法。这相当于Decorator模式中的Component类。

ByteArrayOutputStream，FileOutputStream 和 PipedOutputStream 三个类都直接从OutputStream继承，以ByteArrayOutputStream为例：

以下是代码片段： public class ByteArrayOutputStream extends OutputStream {          protected byte buf[];          protected int count;         public ByteArrayOutputStream() {   this(32);      }          public ByteArrayOutputStream(int size) {          if (size 〈 0) {              throw new IllegalArgumentException("Negative initial size: "                                                 + size);          }   buf = new byte[size];      }          public synchronized void write(int b) {   int newcount = count + 1;   if (newcount 〉 buf.length) {       byte newbuf[] = new byte[Math.max(buf.length 〈〈 1, newcount)];       System.arraycopy(buf, 0, newbuf, 0, count);       buf = newbuf;   }   buf[count] = (byte)b;   count = newcount;      }      ...  }

它实现了OutputStream中的write(int b)方法，因此我们可以用来创建输出流的对象，并完成特定格式的输出。它相当于Decorator模式中的ConcreteComponent类。

接着来看一下FilterOutputStream，代码如下：

以下是代码片段： public class FilterOutputStream extends  OutputStream {         protected OutputStream out;         public FilterOutputStream(OutputStream out) {  this.out = out;     }          public void write(int b) throws IOException {  out.write(b);     }     ... }

 

     同样，它也是从OutputStream继承。但是，它的构造函数很特别，需要传递一个OutputStream的引用给它，并且它将保存对此对象的引 用。而如果没有具体的OutputStream对象存在，我们将无法创建FilterOutputStream。由于out既可以是指向 FilterOutputStream类型的引用，也可以是指向ByteArrayOutputStream等具体输出流类的引用，因此使用多层嵌套的方 式，我们可以为ByteArrayOutputStream添加多种装饰。这个FilterOutputStream类相当于Decorator模式中的 Decorator类，它的write(int b)方法只是简单的调用了传入的流的write(int b)方法，而没有做更多的处理，因此它本质上没有对流进行装饰，所以继承它的子类必须覆盖此方法，以达到装饰的目的。

      BufferedOutputStream 和 DataOutputStream是FilterOutputStream的两个子类，它们相当于Decorator模式中的 ConcreteDecorator，并对传入的输出流做了不同的装饰。以BufferedOutputStream类为例：

以下是代码片段： public class BufferedOutputStream extends FilterOutputStream {        ...   private void flushBuffer() throws IOException {          if (count 〉 0) {       out.write(buf, 0, count);       count = 0;          }      }  public synchronized void write(int b) throws IOException {   if (count 〉= buf.length) {       flushBuffer();   }   buf[count++] = (byte)b;      }        ... }

 

这个类提供了一个缓存机制，等到缓存的容量达到一定的字节数时才写入输出流。首先它继承了 FilterOutputStream，并且覆盖了父类的write(int b)方法，在调用输出流写出数据前都会检查缓存是否已满，如果未满，则不写。这样就实现了对输出流对象动态的添加新功能的目的。
   下面，将使用Decorator模式，为IO写一个新的输出流。

自己写一个新的输出流
   了解了OutputStream及其子类的结构原理后，我们可以写一个新的输出流，来添加新的功能。这部分中将给出一个新的输出流的例子，它将过滤待输出 语句中的空格符号。比如需要输出"java io OutputStream"，则过滤后的输出为"javaioOutputStream"。以下为SkipSpaceOutputStream类的代码：

以下是代码片段： import java.io.FilterOutputStream; import java.io.IOException; import java.io.OutputStream; /**  * A new output stream, which will check the space character  * and won’t write it to the output stream.   * @author Magic  *  */ public class SkipSpaceOutputStream extends FilterOutputStream {  public SkipSpaceOutputStream(OutputStream out) {   super(out);  }  /**   * Rewrite the method in the parent class, and   * skip the space character.   */  public void write(int b) throws IOException{   if(b!=’ ’){    super.write(b);   }  } }

它从FilterOutputStream继承，并且重写了它的write(int b)方法。在write(int b)方法中首先对输入字符进行了检查，如果不是空格，则输出。

以下是一个测试程序：

以下是代码片段： import java.io.BufferedInputStream; import java.io.DataInputStream; import java.io.DataOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /**  * Test the SkipSpaceOutputStream.  * @author Magic  *  */ public class Test {  public static void main(String[] args){   byte[] buffer = new byte[1024];      /**    * Create input stream from the standard input.    */   InputStream in = new BufferedInputStream(new DataInputStream(System.in));      /**    * write to the standard output.    */   OutputStream out = new SkipSpaceOutputStream(new DataOutputStream(System.out));      try {                      System.out.println("Please input your words: ");    int n = in.read(buffer,0,buffer.length);    for(int i=0;i〈n;i++){     out.write(buffer[i]);    }   } catch (IOException e) {    e.printStackTrace();   }  } }

执行以上测试程序，将要求用户在console窗口中输入信息，程序将过滤掉信息中的空格，并将最后的结果输出到console窗口。比如：

以下是引用片段： Please input your words: a b c d e f  abcdef

总    结

在java.io包中，不仅OutputStream用到了Decorator设计模式， InputStream，Reader，Writer等都用到了此模式。而作为一个灵活的，可扩展的类库，JDK中使用了大量的设计模式，比如在 Swing包中的MVC模式，RMI中的Proxy模式等等。对于JDK中模式的研究不仅能加深对于模式的理解，而且还有利于更透彻的了解类库的结构和组 成。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=551960

 

 

 

 大卫的Design Patterns学习笔记11：Decorator

一、        概述
继承是对类进行扩展，以提供更多特性的一种基本方法，但是有时候，简单的继承可能不能满足我们的需求。如我们的系统需要提供多种类型的产品：
类型A、类型B、 ...
同时，这些产品需要支持多种特性：
特性a、特性b、 ...
以下是两种可能的实现：
1、继承，分别实现类型Aa、类型Ab、类型Ba、类型Bb、 ...
这种实现方式在类型的数目和所支持特性的数目众多时会造成“类爆炸”，即会引入太多的类型，并且，这种实现的封装性也很差，造成客户代码编写十分困难，十分不可取。
2、修改各类型实现，在其中包含是否支持特性a、特性b、 ...选项，根据客户选择启用各特性。这种实现是典型的MFC实现方法，但是这种实现只适合特性非常稳定的情况，否则，当特性发生增减时，各类型实现都可能需要修改。
因此，虽然类似的实现屡见不鲜，但以上两种实现方式由于对特性的变化或者类型的变化过于敏感，无法满足类型或特性动态变化的设计需求。如果我们可以将类型和特性分别定义，并且根据客户代码的需要动态对类型和特性进行组合，则可以克服上述问题。
正如Decorator（装饰）模式的名字暗示的那样，Decorator模式可以在我们需要为对象添加一些附加的功能 /特 性时发挥作用，除此之外，更为关键的是Decorator模式研究的是如何以对客户透明的方式动态地给一个对象附加上更多的特性，换言之，客户端并不会觉 得对象在装饰前和装饰后有什么不同。Decorator模式可以在不创造更多子类的情况下，将对象的功能加以扩展。Decorator模式使用原来被装饰 的类的一个子类的实例，把客户端的调用委派到被装饰类，Decorator模式的关键在于这种扩展是完全透明的。
正因为Decorator模式可以动态扩展decoratee所具有的特性，有人将其称为“动态继承模式”，该模式基于继承，但与静态继承下进行功能扩展不同，这种扩展可以被动态赋予decoratee。

二、结构
Decorator模式的结构如下图所示：

图1：Decorator模式类图示意
在上面的类图中包括以下组成部分：
1、Component（抽象构件）角色：给出一个抽象接口，以规范准备接收附加责任的对象。 
2、Concrete Component（具体构件）角色：定义一个将要接收附加责任的类。 
3、Decorator（装饰）角色：持有一个Component对象的实例，并定义一个与抽象构件接口一致的接口。 
4、Concrete Decorator（具体装饰）角色：负责给构件对象“贴上”附加的责任。

三、应用
在以下情况下可以考虑使用Decorator模式：
1、在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。（见示例）
2、处理那些可以撤消的职责。（与上面类似，当有这种动态添加撤销的需求时，可以为类添加相应的装饰类成员，但想要撤销装饰时，将该成员设置为NULL即可，同样，要支持动态切换也很容易）
3、当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈指数增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。（只要你学过排列组合，这一点应该不难理解）

Decorator和Adapter的不同在于前者不改变接口而后者则提供新的接口。可以将Decorator视为一个退化的、仅有一个组件的Composite，然而，Decorator的目的在于给对象添加一些额外的职责，而不是对象聚集。

既然Decorator模式如此强大，是不是可以大加推广，大量运用Decorator来替代简单的继承呢？这样，直接通过继承来扩展类的功能就可以退出历史舞台了！实际上这是不可能的，主要原因如下：
1、虽然“继承破坏了封装性”（父类向子类开放了过多的权限），但是，继承关系是客观世界及OOP中最基本的关系，而且，继承是深化接口规范的基础，没有继承就没有多态等诸多OO特性，因此，继承比Decorator更常见，也更容易定义和实现；
2、由于Decorator动态叠加及不影响decoratee等特性的要求，Decorator很难用于复杂特性的定义；
3、Decorator是一种聚合与继承的结合，应用Decorate模式还存在着其它一些限制，具体将在实现举例部分讨论。

四、优缺点
使用装饰模式主要有以下的优点：
1、装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。 
2、通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。 

使用装饰模式主要有以下的缺点：
由于使用装饰模式，可以比使用继承关系需要较少数目的类，使用较少的类，固然使设计比较易于进行，但是，在另一方面，Decorator的缺点是会产生一些极为类似的小型对象，这些小型对象是为了提供极少量的特殊功能而定制的。

五、举例
Decorator 模式基本的实现方式如下：Decorator类从待修饰类ConcreteComponent的基类Component派生，以便与 ConcreteComponent保持相同的接口，同时，在内部将所有函数调用转发给内部包容的ConcreteComponent对象来执行（1、被 包容的ConcreteComponent对象通过Decorator的构造函数传入。2、往往会附加一些“修饰”，否则，Decorator就徒有虚名 了）。

在下面的例子中，xsstream用于对sstream进行Decorate，以统计调用operator  <<的次数，示例代码如下：

#include <iostream>
using namespace std ;

struct stream
{
    virtual stream & operator  <<(int i ) = 0 ;
    virtual stream & operator  <<(const char * str ) = 0 ;
};

struct sstream  : public stream
{
    stream & operator  <<(int i )
    {
        cout  << i ;
        return  *this ;
    }
    stream & operator  <<(const char * str )
    {
        cout  << str ;
        return  *this ;
    }
};

class xsstream  : public stream
{
    static int count ;
    stream * ps ;
public :
    xsstream (stream * s ) : ps (s ) {}

    stream & operator  <<(int i ) {
        *ps  << "This is ["  << ++count  << "] call to operator <<. i = "  << i  << "
" ;
        return  *this ;
    }
    stream & operator  <<(const char * str ) {
        *ps  << "This is ["  << ++count  << "] call to operator <<. str = "  << str  << "
" ;
        return  *this ;
    }
};
int xsstream ::count  = 0 ;

int main () {
    sstream ss ;
    stream * ps  = new xsstream (&ss );
    stream & s  = *ps ;

    int i  = 1 ;
    s  << i  << "abc" ;

    delete ps ;

    return 0 ;
}

以上方法实现的Decorator模式实质上是对包容的扩展（由于只有一个ConcreteComponent，它看起来很像Proxy模式，但意图不同），虽然以上示例没有什么应用价值，但它基本阐明了Decorator实现的基本方法：
重 新定义Decoratee中的接口方法（由于Decorator与Decoratee从相同基类派生，所以这是可能的），在其中添加必要的 Decoration，并调用Decoratee的相应方法完成Decoration以外的工作，对于无需修饰的辅助方法，可以直接将方法调用转发给 Decoratee。

但是，上述实现同时也告诉了我们Decorator模式存在的一个非常重要的限制，就是：
如果我们从抽象基类派生，我们必须实现抽象基类的每一个虚方法（或者，对于非虚基类，要么重载基类的方法，要么使用基类的实现，但这就丢失了ConcreteComponent子类中重载的实现，即失去（ -）了特性，这与Decorator模式进行修饰，即加（ +）特性的实质有悖），而当虚方法的数目众多时，这将成为一种负担。如实际basic_ostream实现的operator  <<有多种，分别用于bool、short、unsigned short、long、longlong ...等等，逐一实现它们是一件很繁琐的事情。
要 解决这一问题，可以从sstream而不是stream派生，当我们只需要装饰已经实现的一部分方法时这一招似乎“很管用”，但这有悖于 Decorator模式的初衷。因为，Decorator模式提出的目的在于修饰一个类系，而不是单个的类。如果单纯的为了修饰单个的类，简单的继承扩展 即可解决问题，根本就无需从Decorator的角度来考虑这个问题，而如果面对的是多个类，这种方式使我们必须再次面对“类组合爆炸”的窘境。
幸好以上这个问题对于基于消息 /事件的应用中不存在，如在MFC中，进行界面修饰时，可以只需要特别修饰的消息进行处理，而将所有其它消息转发给待修饰的控件。
这 么看来Decorator模式似乎在MFC应用中大有用武之地，但事实并非如此，之所以出现这种局面，大概是因为其一Decorator模式会使得客户代 码变得复杂，我们必须自己创建特性，而不是在Create时直接指定，MFC的实现者希望MFC封装类保持与API一样的接口，在将特性在创建控件时静态 指定与由用户动态创建并指定之间，MFC的实现者选择了前者；其二，从上面可以看出，Decorator模式对于小特性的定义比较合适，当特性或类系十分 复杂时，Decorator模式很难做到面面俱到。

在Java中，java .io .LineNumberReader是一个典型的Decorator，可以Decorate整个Reader类系，用于在读取文件信息的同时统计LineNumber信息，你可以在readLine后通过LineNumberReader .getLineNumber方法获取当前的行号，其实现比较简单，有兴趣的朋友可以研究一下。

参考：
1、Java中Decorate的三种实现方法：http : //www.china-dev.com/2004/04/17/10115.html
注：上文讲述的是Decorate，而不是Decorator，如果将Decorate改成Decorator，则部分观点是不恰当的，如JScrollPane修饰JTextArea，严格来讲应用的是组合模式，而不是Decorator模式，阅读时需注意。