试着发挥静态类型语言的最大功效

Debasish Ghosh 对一场动态 VS. 静态语言的讨论做出了回应，提出了用静态语言编程时动态类型检查的使用问题。他回忆了 Greenspun 第十编程法则：“任何使用静态类型检查语言编写的、足够复杂的程序都包含一个特定、非正式定义、容易引入 Bug 且缓慢的动态检查语言实现。”

Ghosh 认为如今不一定要这样。他主张，Java 泛型（比如 Guice 和 EasyMock）能避免那些为了强制执行运行时类型检查而采取的权宜之计：

原先在有些情况下不得不模拟运行时类型检查，既缓慢又容易引入 Bug，而利用 Java 泛型，这些框架就可以通过编译时类型检查来达到同样的效果。Guice 和 EasyMock 是我用过的比较优秀的两个框架，它们利用泛型实现了突出的类型安全。[……]

看一下下面这段代码，它用 Guice Binder 把实现SpecialServiceImpl绑定到接口Service上。

public class MyModule implements Module {

    public void configure(Binder binder) {

            binder.bind(Service.class)

                         .to(SpecialServiceImpl.class)

                         .in(Scopes.SINGLETON);

    }

}

尽管“Service和SpecialServiceImpl之间的“实现”关系看起来是在运行时完成的”，但所有的类型检查实际上是在编译时进行的：

快速看一下 Guice 的源码，可以看到 BinderImpl.bind() 方法返回 BindingBuilderImpl……

public BindingBuilderImpl bind(Class clazz) {

    return bind(Key.get(clazz));

} 

BindingBuilderImpl.to() 方法则把Class 作为输入——加在类型通配符上的限制使对参数的编译时类型检查实际上起到检查“实现”关系的作用……

public ScopedBindingBuilder to(Class extends T> implementation) {

    return to(TypeLiteral.get(implementation));

}

Debasish Ghosh 提倡使用这种解决方法，而不是试图实现动态类型检查。这种方法不仅能避免 Greenspun 第十编程法则，还能充分利用静态类型，因为它能保证强大的类型安全：

在你用静态类型语言编程的时候，利用适当的语言特性让大部分的类型检查在编译时进行。这样，在你点击运行按钮之前，你就能确信你的代码符合类型系统的规则。你还能够对你的代码集进行更为简单的重构和更加清晰的改进。