【第4条】通过私有构造器强化不可实例化的能力

通过私有构造器强化不可实例化的能力

 

偶尔你会想写一个只包含静态方法和静态字段的类。这些类的名声非常不好，因为有些人滥用这些类从而避免以面向对象方式思考从而编写过程化的程序，但是它们确实有着特殊的用途。它们可以用来按照 java.lang.Math 或 java.util.Arrays 的方式，把基本类型的值或数组类型上的相关方法组织起来。我们也可以通过 java.util.Collections 的方式，把实现特定接口上面的静态方法进行分组，也包括工厂方法。（从 Java 8 开始，你也可以将这些方法放在接口中，假定该接口是你编写的并可以进行修改。）最后，这样的类可以用于在 final 类上对方法进行分组，因为不能将它们放在子类中。

 

这样的工具类（utility classes）不是设计用来被实例化的，因为实例化对它没有任何意义。然而，在没有显式构造器的情况下，编译器提供了一个公共的、无参的默认构造器。对于用户来说，该构造器与其他构造器没有什么区别。在已发布的 API 中经常看到无意识的被实例的类。

 

试图通过创建抽象类来强制执行非实例化是行不通的。该类可以被子类化，并且子类可以被实例化。此外，它误导用户认为该类是为继承而设计的。不过，有一个简单的方法来确保非实例化。只有当类不包含显式构造器时，才会生成一个默认构造器，因此只要让这个类包含一个私有构造器，它就不能被实例化

// Noninstantiable utility class public class UtilityClass {     // Suppress default constructor for noninstantiability     private UtilityClass() {         throw new AssertionError();     }    ... // Remainder omitted }

因为显式构造器是私有的，所以不可以在类的外部访问它。AssertionError 异常不是严格要求的，但是它可以避免不小心在类的内部调用构造器。它保证类在任何情况下都不会被实例化。这个习惯用法有点违反直觉，好像构造器就是设计成不能调用的一样。因此，如前面所示，添加注释是种明智的做法。

 

这种习惯有一个副作用，就是使得一个类不能子类化。所有的构造器都必须显式或隐式地调用父类构造器，而在这群情况下子类则没有可访问的父类构造器来调用。

 

                                                                                  扫描二维码(关注我)、获取更多精彩