我自闲庭信步,悠然自得,不亦乐乎.

                                       ------ Keep life simple
GMail/GTalk/MSN:huyi.zg@gmail.com

 

关于文件操作的封装处理

File类本身并不持有文件句柄,它只是集中了一系列对文件的操作方法,如Create,Open等等。这些方法全部都是静态的,也不进行任何的安全检测,仅仅是直接调用pspsdk来完成任务,如果出现错误,则返回负值。
File的Open等方法可以创建针对指定文件读写的流对象FileStream,句柄由FileStream自己创建和持有管理,File::Open只是传达路径信息。
可以把File看作是一个门面,集中了对文件的所有操作,并且不需要创建File对象就可以直接执行这些操作。所以说File为文件的单一操作提供了快捷简便的方式。
除了几个创建FileStream流的操作外,其他操作都不会长期占用句柄资源,遵循"句柄创建-执行具体操作-释放句柄"的步骤。

如果需要频繁的操作文件,则需要一个类来长期持有句柄,避免经常性的打开和关闭文件,故此引入FileInfo类。FileInfo执行Append等操作时,都是使用事先打开的文件句柄。
同时,FileInfo也可以创建FileStream实例,但这个时候,文件的句柄生命周期应该由FileInfo来管理,FileStream可以使用这个句柄,但不能结束其生命周期,FileStream::Close()方法仅仅使这个流处于关闭(不可读写)状态,但并不实际关闭文件句柄。
这种情况下,FileInfo所创建的FileStream::Close()的行为和前面File所创建的FileStream::Close()行为有差异。因为File并不持有句柄,所以它创建了FileStream对象后,句柄应该由FileStream来管理。但FileInfo所创建的FileStream是使用的FileInfo所创建好的句柄,所以它并不对此句柄负责。

实现策略:
1.使用基于继承的多态或基于模板的静多态。
2.使用函数回调。把Close做成调用函数指针,通过不同的FileStream构造函数调用,来设置指针指向不同的Close函数实现。(关闭句柄或不关闭句柄)
这两种做法的优劣性正在考证中,请提出意见。


补充:File和FileInfo的关系在dotnet中也有体现,不过他们主要是从错误检测方面考虑。
最终的目的是要为客户提供一个统一的界面,所以不能用太复杂的模板。

经过慎重考虑,我还是决定用虚函数,放弃了模板。

posted on 2006-10-14 16:45 HuYi 阅读(1087) 评论(0)  编辑 收藏 引用 所属分类: 开发点滴


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿(12)

随笔分类

相册

收藏夹

友情链接

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜