标签：国家 buffered io操作 xtend 二进制文件 原来 err 抽象方法 pre
java使用IO流来处理不同设备之间数据的交互;所有的IO操作实际上都是对 Stream 的操作
输出流: 从程序输出回另一个源成为输出流;
输入与输出是有参照物的,而这个参照物就是应用程序本身
总体的大纲分为两部分,字节流和字符流的封装类体系
首先说:
什么是字符? 所有的英文字符,特殊符号,世界上所有的国家的文字,统称为字符
Java默认一次性处理8位,也就是一个字节
节点流 : 从特定的地方读写的流类 , 比如, 从磁盘或者内存区域
例: 我们想从文件中读取数据,于是我们创建 FileInputStream() , 这个流称为节点流
过滤流 : 这种流会使用节点流作为输入输出(把节点流作为构造方法的参数) FilterInputStream
过滤流也会包装过滤流---> 装饰者设计模式
open a stream
while more information
read information
close the stream例:
//创建一个文件输入流对象,并关联上src下的xanadu
FileInputStream fis = new FileInputStream("src/xanadu");
int b; //定义变量,记录每次读到的字节
while((b = fis.read()) != -1) { //将每次读到的字节赋值给b并判断是否是-1
System.out.println(b); //打印每一个字节
}
fis.close();文件中内容是: a312a
输出的结果是: 97 51 49 50 97
按照字节读取 a312a 得到的结果 分别是他们的 ASCII表的值
为什么按照字节读,返回的结果不是byte而是整形呢?
因为字节输入流可以操作任意类型的文件,比如图片音频等,这些文件底层都是以二进制形式的存储的,如果每次读取都返回byte,有可能在读到中间的时候遇到111111111
那么这11111111是byte类型的-1,我们的程序是遇到-1就会停止不读了,后面的数据就读不到了,所以在读取的时候用int类型接收,如果11111111会在其前面补上
24个0凑足4个字节,那么byte类型的-1就变成int类型的255了这样可以保证整个数据读完,而结束标记的-1就是int类型
所以,当我们使用二进制文件输出流往文件中 write(97) 就会写进去a
节点流和过滤流的搭配使用, 当我们想从 file中读取数据, 于是我们创建
FileInputStream()关联磁盘上的文件, 然后我们又想提升的效率让我们的inputStream拥有缓存的能力,于是为我们为他包装上了BufferedInputStream,然后我们想把流里面的字节数据转换成我们看的懂的基本数据类型,于是我们又包装上了一层DataInputStream最终用户使用的就是DataInputStream的实例
open a stream
while more information
write information
close the streamabstract void write(int b); // 往输出流中写入一个字节
void write(byte[]b) ; // 往输出流中写入 字节数组b中全部的字节
void write(byte[]b,int off,int len); // 往字节数组中写入从off 开始 len个长度的字节
void flush(); //刷新输出流
void close(); // 关闭所以当我们进行文件的拷贝的时候我们一般会这样写:
FileInputStream fis = new FileInputStream("1.txt"); //创建输入流对象,关联1.txt
FileOutputStream fos = new FileOutputStream("2.txt");//创建输出流对象,关联2.txt
int b;
while((b = fis.read()) != -1) {
fos.write(b);
}
fis.close();
fos.close()
如图是Output链
字符流先读取到的是字节,进而把字节转换为字符,如果要写出字符的话,需要先把字符转换为字节再写出去, 字符流的出现是对字节流的一层包装
如下:
FileReader fr = new FileReader("aaa.txt"); //创建输入流对象,关联aaa.txt
int ch;
while((ch = fr.read()) != -1) { //将读到的字符赋值给ch
System.out.println((char)ch); //将读到的字符强转后打印
}
因为他按照字符读取,所以我们可以尝试强制转换为 char类型的符号
同理,它的write方法可以往文件里面 写入 字符串
像这样的代码:
new DataInputStream(new BufferedInputStream(new FileInputStream()));它是java IO库中提供的一个称为链接的机制, 可以将流首尾相连,形成一个管道, 称为 Decorator 装饰者设计模式
装饰设计模式的组件
在java的IO体系中各部分所属的组件如下图
装饰者接收到给定的对象后,把用户使用装饰者的方法转发给被装饰者,并在这个转发前后添加自己特定的功能, 从而可以在代码运行时,不用修改给定对象的结构就添加了新的功能. (而在面向对象的设计中,通常是被设计成 继承给定对象所属的类) , 一句话总结: 装饰者模式是在扩展给定的对象
下面模拟JavaIO,写一个例子
首先是顶级接口Component:
public interface InputStreamComponent {
void read();
}Concrete Component 具体的实现组件
public class FileInputStreamConcreteComponent implements InputStreamComponent {
@Override
public void read() {
System.out.println("FileInputStreamConcreteComponent 读取字节流 ...");
}
}Decorator 和具体的实现组件位于同一级
// todo 1. 实现了 顶级接口
public class FilterInputStreamDecorator implements InputStreamComponent {
// 2. 持有顶级接口的引用
private InputStreamComponent inputStreamComponent;
// 3. 在构造函数中初始化
public FilterInputStreamDecorator(InputStreamComponent inputStreamComponent) {
this.inputStreamComponent=inputStreamComponent;
}
// todo 4. 重写的抽象方法, 交由顶级接口的引用完成方法的调用
@Override
public void read() {
inputStreamComponent.read();
}
}
带缓存的装饰者
// todo 当前的装饰者,继承中间层的 Decorator
public class BufferedInputStreamConcreateDecrator extends FilterInputStreamDecorator {
// todo 同样持有顶级接口的引用
private InputStreamComponent inputStreamComponent;
public BufferedInputStreamConcreateDecrator(InputStreamComponent inputStreamComponent) {
// todo 把传递进来的需要的装饰的对象,传递给Decorator中间层, 让它去执行 需要被装饰对象原有的方法
super(inputStreamComponent);
}
@Override
public void read() {
// todo 调用父类的 read
super.read();
this.ARead();
}
private void ARead() {
System.out.println("BufferedInputStreamConcreateDecrator A... 增加缓存的功能...");
}
}读取基本数据类型的装饰者
/ todo 当前的装饰者,继承中间层的 Decorator
public class DataInputStreamConcreateDecrator extends FilterInputStreamDecorator {
// todo 同样持有顶级接口的引用
private InputStreamComponent inputStreamComponent;
public DataInputStreamConcreateDecrator(InputStreamComponent inputStreamComponent) {
// todo 把传递进来的需要的装饰的对象,传递给Decorator中间层, 让它去执行 需要被装饰对象原有的方法
super(inputStreamComponent);
}
@Override
public void read() {
// todo 调用父类的 read
super.read();
this.ARead();
}
private void ARead() {
System.out.println("BufferedInputStreamConcreateDecrator 进一步把流转换成基本数据类型 ...");
}
}下面是测试
public class text {
public static void main(String[] args) {
InputStreamComponent DataInputStreamConcreateDecrator =
new DataInputStreamConcreateDecrator(
new BufferedInputStreamConcreateDecrator(
new FileInputStreamConcreteComponent()));
DataInputStreamConcreateDecrator.read();
System.out.println("");
InputStreamComponent DataInputStreamConcreateDecrator2 =
new DataInputStreamConcreateDecrator(
new FileInputStreamConcreteComponent());
DataInputStreamConcreateDecrator2.read();
}
}结果:
FileInputStreamConcreteComponent 读取字节流 ...
BufferedInputStreamConcreateDecrator A... 增加缓存的功能...
BufferedInputStreamConcreateDecrator 进一步把流转换成基本数据类型 ...
FileInputStreamConcreteComponent 读取字节流 ...
BufferedInputStreamConcreateDecrator 进一步把流转换成基本数据类型 ...依然是,根据源的不同,选择不同的 具体实现的组件Concrete Compent 得先把数据读取到InputStream里面,进而选择不同的装饰者对输入流进行包装
中间层设计的很巧妙,1. 中间层实现了顶级接口,而所有的装饰者又继承于中间层, 达到了规范装饰者的目的 2.对于要去重写的顶级接口的方法来说,中层其实他本身啥活也没干,相反他使用自己的成员变量 (顶级接口的引用去完成重写的工作) 而这个引用不是别人,就是用户传递进去的直接关联数据源的对象
装饰者:
继承:
这是一个静态代理的例子:
interface Logger {
void writeLog();
}
// 被代理类
class LoggerSubject implements Logger{
@Override
public void writeLog(){
System.out.println("writeLog by LoggerSubject");
}
}
// 代理类
class Proxy implements Logger{
Logger logger;
// 与装饰者模式的主要区别位置
// 代理模式一般要求和原来的类行为一致，因此构造函数不传入对象
Proxy(){
this.logger = new LoggerSubject();
}
@Override
public void writeLog(){
System.out.println("logger write before");
logger.writeLog();
System.out.println("logger write after");
}
}
public class StaticProxy {
private static void write(Logger logger){
logger.writeLog();
}
public static void main(String []argvs){
Logger logger = new Proxy();
write(logger);
}
}相同点:
不同点:
在使用的时候最直观的不同点就是: 静态代理把被代理的对象隐藏起来了,客户端使用代理对象的时候,是感觉不出有被代理的对象存在的; 而装饰者模式的层级关系很明确
但是它们的侧重点不同, 代理设计模式的侧重点是增加对代理对象方法的控制,比如我想在目标方法执行前后都打印一下日志,而 javaIO的装饰者模式侧重于添加功能,比如先得到 输入流--> 添加缓存 --> 把输入流转换成基本数据类型 类似的这样的功能的添加
标签：国家 buffered io操作 xtend 二进制文件 原来 err 抽象方法 pre
原文地址：https://www.cnblogs.com/ZhuChangwu/p/11150378.html
