Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenDocCN
thinking-in-java-zh
提交
a6b56360
T
thinking-in-java-zh
项目概览
OpenDocCN
/
thinking-in-java-zh
通知
0
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
T
thinking-in-java-zh
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
a6b56360
编写于
5月 07, 2016
作者:
Q
quanke
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update 16.4 改进设计.md
上级
ee546ce4
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
1 addition
and
0 deletion
+1
-0
16.4 改进设计.md
16.4 改进设计.md
+1
-0
未找到文件。
16.4 改进设计.md
浏览文件 @
a6b56360
...
...
@@ -421,4 +421,5 @@ public class RecycleAP {
所有Trash对象——以及ParseTrash及支撑类——现在都成为名为c16.trash的一个包的一部分,所以它们可以简单地导入。
无论打开包含了Trash描述信息的数据文件,还是对那个文件进行解析,所有涉及到的操作均已封装到static(静态)方法ParseTrash.fillBin()里。所以它现在已经不是我们设计过程中要注意的一个重点。在本章剩余的部分,大家经常都会看到无论添加的是什么类型的新类,ParseTrash.fillBin()都会持续工作,不会发生改变,这无疑是一种优良的设计方案。
提到对象的创建,这一方案确实已将新类型加入系统所需的变动严格地“本地化”了。但在使用RTTI的过程中,却存在着一个严重的问题,这里已明确地显露出来。程序表面上工作得很好,但却永远侦测到不能“硬纸板”(Cardboard)这种新的废品类型——即使列表里确实有一个硬纸板类型!之所以会出现这种情况,完全是由于使用了RTTI的缘故。RTTI只会查找那些我们告诉它查找的东西。RTTI在这里错误的用法是“系统中的每种类型”都进行了测试,而不是仅测试一种类型或者一个类型子集。正如大家以后会看到的那样,在测试每一种类型时可换用其他方式来运用多形性特征。但假如以这种形式过多地使用RTTI,而且又在自己的系统里添加了一种新类型,很容易就会忘记在程序里作出适当的改动,从而埋下以后难以发现的Bug。因此,在这种情况下避免使用RTTI是很有必要的,这并不仅仅是为了表面好看——也是为了产生更易维护的代码。
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录