返回介绍

10.10 总结

发布于 2024-10-15 23:56:24 字数 924 浏览 0 评论 0 收藏 0

Java IO 流库能满足我们的许多基本要求:可以通过控制台、文件、内存块甚至因特网(参见第 15 章)进行读写。可以创建新的输入和输出对象类型(通过从 InputStream 和 OutputStream 继承)。向一个本来预期为收到字串的方法传递一个对象时,由于 Java 已限制了“自动类型转换”,所以会自动调用 toString() 方法。而我们可以重新定义这个 toString(),扩展一个数据流能接纳的对象种类。

在 IO 数据流库的联机文档和设计过程中,仍有些问题没有解决。比如当我们打开一个文件以便输出时,完全可以指定一旦有人试图覆盖该文件就“掷”出一个违例——有的编程系统允许我们自行指定想打开一个输出文件,但唯一的前提是它尚不存在。但在 Java 中,似乎必须用一个 File 对象来判断某个文件是否存在,因为假如将其作为 FileOutputStream 或者 FileWriter 打开,那么肯定会被覆盖。若同时指定文件和目录路径,File 类设计上的一个缺陷就会暴露出来,因为它会说“不要试图在单个类里做太多的事情”!

IO 流库易使我们混淆一些概念。它确实能做许多事情,而且也可以移植。但假如假如事先没有吃透装饰器方案的概念,那么所有的设计都多少带有一点盲目性质。所以不管学它还是教它,都要特别花一些功夫才行。而且它并不完整:没有提供对输出格式化的支持,而其他几乎所有语言的 IO 包都提供了这方面的支持(这一点没有在 Java 1.1 里得以纠正,它完全错失了改变库设计方案的机会,反而增添了更特殊的一些情况,使复杂程度进一步提高)。Java 1.1 转到那些尚未替换的 IO 库,而不是增加新库。而且库的设计人员似乎没有很好地指出哪些特性是不赞成的,哪些是首选的,造成库设计中经常都会出现一些令人恼火的反对消息。

然而,一旦掌握了装饰器方案,并开始在一些较为灵活的环境使用库,就会认识到这种设计的好处。到那个时候,为此多付出的代码行应该不至于使你觉得太生气。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文