诊断Java代码: 使用静态类型的理由

静态类型 ― 多数程序员喜欢它或憎恨它。支持者夸耀说静态类型让他们写出更干净更可靠的代码，没有它们则做不到这么好。批评者埋怨说静态类型增加了程序的复杂性。

是的，静态类型不是免费午餐；有时候，它们用起来很乏味。然而，如果我们主要关心的是使代码没有错误，那么，总的说来，Java 编程还是拥有并使用静态类型好些。为什么？静态类型检查：

通过早期错误检测，提高健壮性

通过在最佳的时候作所需的检查，提高性能

弥补单元测试的缺点

我们来更仔细地分析这些原因，并看一看静态类型检查和结对编程（pair programming）混用。

通过早期检测，提高健壮性

静态类型检查能提高程序健壮性。为什么？因为它有助于尽快找到错误 ― 在程序运行前。这里的逻辑舍此无它。错误越早被发现，问题诊断起来就越容易，也就只有越少的数据会被错误的计算毁坏。

在程序运行前就找到并诊断错误是理想状态。这个优点使静态类型检查成为编程语言设计中的伟大成功，因为它是少数几种能在程序运行前自动检测程序中的错误的方法，而且它可在可接受的时间内完成这个任务。“可接受的时间”意思是与程序长度呈线性关系的时间（有一个很小的常数系数），而不是其它形式自动检查所要求的呈立方甚至呈指数关系的时间（许多甚至根本不保证完成）。

是的，类型系统越强大，编起程序来就越容易（且系统将检测越多的错误）。我不否认 Java 简单的类型系统留有很多缺憾；它经常阻碍我们，迫使我们用强制转型来绕过。但这种状况正在慢慢改善。

Sun JSR14 编译器在语言中增加了形式有限的泛型（也称为 参数化）类型；我们相信它迟早会被加入该语言，因为它目前在 Java 社区过程中得到了坚定的支持。更高级的语言扩展（例如 NextGen）承诺在 JSR14 提供的增加的表达力上更上一层楼。那是好事，因为在很多环境下 NextGen 都有助于减少甚至在 JSR14 中也是需要的一些增加的复杂性。请参阅 参考资料找到关于这个问题的更多信息。（除了 JSR14 链接，还有些关于 参数的多态性的文章。）

然而，静态类型检查的好处不仅仅是健壮性。它还能保护您的程序的性能。

通过减少所需的检查，提高性能

在安全的语言中（“安全”的意思是指不允许我们破坏它自己的抽象的语言），对传给方法的参数的类型作各种检查是必需的并一定得完成，对被存取的域的类型的检查也是必需的并一定得完成。如果这些检查不是静态地完成，那么它们必须在运行时完成。

进行这些所需的检查是费时的，在运行时进行这些检查的语言，其性能会相应受损。当不变量被静态地检查时，我们不必在运行时检查它，从而加快程序运行。所以，静态类型检查使我们得以写出更健壮更高效的代码。

传统上认为编译时静态类型检查是低效的。对于用 C/C++ 之类语言写的大程序来说，在文件间链接各种类型引用是很费时的，因为每次编译时，各种文件必须被合在一起生成一个大的可执行文件。但是 Java 语言完全避免了这个问题，因为类是分开编译的，在需要时装入到 JVM。没有必要把所有的引用文件链接成一个可执行文件 ― 所以在编译时没有相应的放慢。

现在，我们对那些声称静态类型在单元测试环境下是不必要的人说些什么呢？

诊断Java代码: 使用静态类型的理由(2)

突破单元测试的限制

本专栏的老读者知道，我是单元测试的坚定支持者。对您的程序全部进行单元测试是最好的作法。然而，我首先要承认单元测试的局限性。

单元测试仅能测试程序在某次特定运行时输入某些特定数据时的行为。是的，在那次运行的狭小环境下，我们可以测试程序的 深层属性。

相对而言，类型

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!