原本是想接着写写的,但是一上网搜搜,结果发现这篇博文《适配器模式和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,对他们中的抽象的未实现的方法给出实现。如:
1 2 3 |
|
如上代码中的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的构造方法。
除此之外,这两个类中没有给出其他的任何实现。
--------------------------------------------------------------------------------------------原文结束---------------------
如果你想接着看JDK中的适配器模式,
- javax.xml.bind.annotation.adapters.XmlAdapter#marshal()
- javax.xml.bind.annotation.adapters.XmlAdapter#unmarshal()
那你去看Java与模式 第24章 专题:XMLProperties与适配器模式,我就不分析了。嗯嗯。。。
注:在业务代码中经常有新旧接口适配需求,可以采用该模式。