道不远人,话IO框架

    近来在看谭振林的《道不远人..》,他告诉我们“道术”的思想,我认为很经典,“术于外,而道在内”,“术合于道,相得益彰;道术相离,各见其害”。这几句话对我受益匪浅。以前太过于最求“术”,微软的新东西太多了,光追求“术”,不断我发现“太累了”,光看那webcast都看不完,于是不断的抱怨跟着微软走是种错误的选择。一年下来没有多少“道”的积累。
    也许是谭大哥给我启示,我本着知其然更要知其所以然的思想开始了本书的历程。不求快,只求益。
   
    当我读到GZipStream对PageState进行压缩的时候,我就傻了。短短十几行代码给了我十几个问号(不要笑,我是初学者)。下面贴出这段代码,也许有和我一样看不懂的,呵呵。
Decompress

Compress

我分析了下,是我对IO框架了解不够。收集些了资料,经过分析,终于有的思想了。先看张IO框架图,一图胜万言。
点击放大
点击放大

Stream 类,MSDN解释,Provides a generic view of a sequence of bytes. 就是有序的字节。
整个继承Stream类系列,采用了Decorator设计模式,当然有的是直接继承,有的是Decorator类。

有关这个设计模式的详细叙述,请看TrerryLee的Decorator设计模式
在代码
  //解压
        MemoryStream ms = new MemoryStream(buffer);
        GZipStream zipStream 
= new GZipStream(ms, CompressionMode.Decompress);
中,如果看完了Decorator模式,就很好理解了。在反编译代码中,GZipStream有个属性property(DeflateStream Class),DeflateStream Class于Stream类关系就是继承关系,于MemoryStream类是装饰关系。GZipStream的属性类DeflateStream在MemoryStream上加了压缩算法。
 public class GZipStream : Stream
    {
        
private DeflateStream deflateStream;
}


    
public class DeflateStream : Stream
    {
        
private Stream _stream;
}

搞清了之后,再寻“道”。
FileSteam,MemoryStream是基于存放数据的介质不同,一个文件,一个是backing store。

以前搞不清楚TextWriter,TextReader,和Stream类关系,现从IO框图和反编译代码中发现他们作为基类没有任何关系。
他们的子类StringWriter和StringReader简直就是对String的处理类,只有StreamWriter和StreamReader都用到Stream类作为参数。
如果要把string于文件介质发生关系,就传FileStream给StreamWriter和StreamReader,
若要和backing store介质发生关系,就传MemoryStream给StreamWriter和StreamReader,可以类推。

当然上面的规律应该也适合BinaryReader和BinaryWriter。

File静态类有Create方法创建FileStream实例。

。。。等等。我想可以结合IO框架图和反编译源代码一一理清关系。有了一定关系,就不用复制别人的代码,而不假思索了。呵呵。



原文地址:https://www.cnblogs.com/ericwen/p/IO.html