java.io包中的字符流(下)—— 适配器模式和InputStreamReader/OutputStreamWriter

在前一篇文章中,我们已经对Java IO中的Reader和Writer做了介绍,并对其中一些实现的使用做了分析和整理。除了上篇文章中提到的那些字符流IO类,Reader和Writer还有InputStreamReader、FileReader和OutputStreamWriter、FileWriter这样4个实现的子类,而他们和字节流之间的关系采用了适配器这种设计模式,我们接下来就对适配器模式和这四个类详细介绍下。

0. 适配器模式 ( Adapter )

我们先来说说JavaIO中用到的适配器模式。谈到设计模式,我们就不得不提GoF经典的著作《Design Patterns: Elements of Reusable Object-Oriented Software》(《设计模式》)。在这本书中,作者将提到的23种设计模式根据应用场景考虑,分为3大类:

  • 构建型设计模式。主要描述几种不同场景下的对象生成的方式。
  • 结构型模式。描述在面向对象设计中,类和对象的几种结构关系。
  • 行为型设计模式。主要是考虑在有Action进来时,信息的传递和行为的执行。

我们这里提到的适配器模式属于结构型设计模式,而Java的字符流IO类Reader/Writer和字节流IO类之间的关系正式以这个适配器模式来设计的。下面我们简要来看下。

适配器模式通常有2种实现方式:一种是类适配,也就是通过类似多继承的形式;而另外一种就是对象适配,通常是通过引用潜入来实现的。我们可以看两张比较直观的类结构图说明,这样就不需要多说明什么了。

适配器模式的类适配方式

适配器模式的类适配方式

当适配的对象调用Request()的方法时,适配器实现类会调用实际父类的SpecificRequest()方法来完成,从而实现了适配。

下面再来看对象适配实现形式。

适配器模式的对象适配方式

适配器模式的对象适配方式

当适配的对象调用Request()的方法时,适配器实现类会调用实际包装嵌入的引用对象的SpecificRequest()方法来完成,从而实现了适配。

最后,在简要说下适配器模式和装饰模式以及代理模式的关系。

  • 装饰模式 ( Decorator )。前面也提到过,是通过对一个已有对象的进一步分装来实现功能上的扩展。这个相对于类扩展继承更为动态化,是基于已有对象而非类的扩展。
  • 代理模式 ( Proxy )。也是通过对一个对象的“封装”,“屏蔽”掉client请求对真实原始对象的直接调用,来增加做访问控制方面的处理逻辑。

单纯从类和对象结构上来看,装饰模式、代理模式和适配器模式(尤其是对象的实现方式)大有相似之处。但之所以这几个是不同的设计模式,是我们设计考虑的出发点和细节不同,从描述中也可以看得出来。

适配器模式偏重的是适配,即实现要适配的接口功能。装饰模式偏重的是对已有对象的功能扩展。而代理模式则偏重的是访问逻辑的控制,因此通常这个代理的构建过程是不直接由client控制的。

1. InputStreamReader和OutputStreamWriter

对于字符流IO类的使用,使用FileReader和FileWriter进行文件读写操作是比较经常用到的。而java.io包中的FileReader和FileWriter类分别继承自InputStreamReader和OutputStreamWriter,而且实际上FileReader和FileWriter的主要实现逻辑都在父类InputStreamReader和OutputStreamWriter中,我们先来看下这两个父类。

InputStreamReader和OutputStreamWriter分别继承自java.io包中的Reader和Writer,对他们中的抽象的未实现的方法给出实现。如:

    public int read(char cbuf[], int offset, int length) throws IOException {
        return sd.read(cbuf, offset, length);
    }

如上代码中的sd(StreamDecoder类对象),在Sun的JDK实现中,实际的方法实现是对sun.nio.cs.StreamDecoder类和sun.nio.cs.StreamEncoder类的同名方法的调用封装。我们可以通过这样两张类结构关系图看下。

字节流到字符流解码的相关类结构关系

字节流到字符流解码的相关类结构关系

我们再来看下OutputStreamWriter相关的类结构关系:

字符流到字节流编码相关类结构关系

字符流到字节流编码相关类结构关系

我们看到这样几点:

  • InputStreamReader和OutputStreamWriter实际上是对同样继承了Reader和Writer的StreamDecoder和StreamEncoder的封装
  • StreamDecoder和StreamEncoder不是Java SE API中的内容,是Sun JDK给出的自身实现。但我们知道他们对构造方法中的字节流类(InputStream和OutputStream)参数和字符集类(Charset)进行了封装,并通过此二者进行了字节流和字符流之间的编码解码转换

从表层来看,InputStreamReader和OutputStreamWriter做了InputStream/OutputStream字节流类到Reader/Writer之间的转换。而从如上Sun JDK中的实现类关系结构中可以看出,是StreamDecoder和StreamEncoder的设计实现在实际上采用了适配器模式。

下面我们再来看看子类FileReader和FileWriter。

2. FileReader和FileWriter

上文多次提到了这两个类,他们分别继承于InputStreamReader和OutputStreamWriter。更重要的是,他们的read和write逻辑,甚至编码解码都是采用父类的。

打开Sun JDK中这两个类的源码实现可以看到,这两个类本身的实现只有几个重载的构造方法。在这几个构造方法中实际所做的事情就是将各类参数最终转为java.io包中的FileInputStream和FileOutputStream字节流类,传给父类,即InputStreamReader和OutputStreamWriter的构造方法。

除此之外,这两个类中没有给出其他的任何实现。

字符流的介绍到此为止,欢迎大家讨论。

作者原创,难免有错误,欢迎读者热心评论留言指出,以免误导他人,谢谢!

此条目发表在 IO, Java, Java语言, 开发, 计算机技术 分类目录,贴了 , , , , , 标签。将固定链接加入收藏夹。

java.io包中的字符流(下)—— 适配器模式和InputStreamReader/OutputStreamWriter》有 1 条评论

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>