有时可能需要编写只包含静态方法和静态域的类 。 这些类的名声很不好,因为有些人在面向对象的语言中滥用这样的类来编写过程化的程序,但它们也确实有特别的用处 。 我们可以利用这种类,以 java. lang. Math 或者 java. util. Arrays 的方式,把基本类型的值或者数组类型上的相关方法组织起来 。 我们也可以通过 java .util .Collections的方式,把实现特定接口的对象上的静态方法,包括工厂方法组织起来 。(从Java 8 开始,也可以把这些方法放进接 口中,假定这是你自己编写的接口可以进行修改 。)最后,还可以利用这种类把 final 类上的方法组织起来,因为不能把它们放在子类中 。
这样的工具类( utility class )不希望被实例化,因为实例化对它没有任何意义 。 然而 ,在缺少显式构造器的情况下,编译器会自动提供一个公有的 、无参的缺省构造器( default constructor ) 。对于用户而言,这个构造器与其他的构造器没有任何区别 。 在已发行的 API中常常可以看到一些被无意识地实例化的类 。
企图通过将类做成抽象类来强制该类不可被实例化是行不通的 。该类可以被子类化,并且该子类也可以被实例化 。这样做甚至会误导用户,以为这种类是专门为了继承而设计的 然而,有一些简单的习惯用法可以确保类不可被实例化 。 由于只有当类不包含显式的构造器时,编译器才会生成缺省的构造器,因此只要让这个类包含一个私有构造器,它就不能被实例化:
// Noninstantiable utility class
public class UtilityClass {
// Suppress default constructor for nonins tantiability
private UtilityClass() {
throw new AssertionError();
}
... // Remainder omitted
}
由于显式的构造器是私有的,所以不可以在该类的外部访问它 。AssertionError 不是必需的,但是它可以避免不小心在类的内部调用构造器 。 它保证该类在任何情况下都不会被实例化 。 这种习惯用法有点违背直觉,好像构造器就是专门设计成不能被调用一样 。因此,明智的做法就是在代码中增加一条注释,如上所示 。
这种习惯用法也有副作用,它使得一个类不能被子类化 。 所有的构造器都必须显式或隐式地调用超类( superclass )构造器,在这种情形下,子类就没有可访问的超类构造器可调用了 。