诊断Java代码: 使用静态类型的理由 - 编程入门网
检查检查 浅层属性,但它针对的是该程序所有可能的运行和各种可能的输入。
结合类型检查和单元测试 正如指定程序行为时,素材和单元测试互相补充一样,在确定和排除错误时,单元测试和静态类型检查互相补充。这两种排错方法的结合效果大于它们各自的效果之和。 有些设计师和程序员会提出,成熟的程序中发生的错误种类比静态类型检查能发现的要深得多;所以,他们的结论是静态类型系统的弊大于利。无疑,静态类型语言使程序更冗长,甚至阻止我们写出一些从不引起任何错误的程序。 总是有折衷。使用静态类型并不是免费的午餐。我们用静态类型语言写的程序常常要比我们不使用类型系统写的程序更复杂。但是,甚至“成熟”程序也会有那种浅层错误,成为静态类型检查的特别猎物。 即使程序中的这些浅层错误被消灭,重构也很容易就会重新产生它们。如果我们打算采纳不断重构的极端编程思想,我们将在这样的浅层错误被引入后尽快地捕获它们。(相反地,单元测试有助于捕获重构时发生的更深层错误。这两个概念的整体之和大于它们的部分之和。)在极端编程的环境下,静态类型检查效果不错。 类型检查和单元测试的矛盾 尽管如此,静态类型检查和单元测试之间仍有一个须提到的矛盾。极端编程要求我们把单元测试的编写和代码的编写交叉起来以实现那些测试。 每组单元测试有助于指定功能性的一个新方面,应写在允许我们通过那些测试的代码之前。在理想情况下,我们要在写完它们后马上编译那些测试,这样我们可以确保它们已准备就绪。 但这里有一个问题: 在我们定义测试所引用的类和方法前,新测试不能通过静态类型检查。这些类和方法可以是我们以后填充的空架子,但是除非我们有点东西,否则静态检查器会认为在测试中引用它们是没意义的。 考虑清单 1 中比较简单的示例,它显示了一个多集合(multi-set)的实现的测试类(一个抽象的数据结构): 清单 1. 一个多集合的实现的测试类
|
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |