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

阅读原文
04-通过私有化构造器强化不可实例化的能力
  有时候，可能需要编写只含有静态方法和静态域的类。这些类的名声很不好。因为有些人在面向对象的语言中滥用这样的类来编写过程化的程序。尽管如此，它们也确实有它们的用处。我们可以利用这种类，一java.lang.Math或者java.util.Arrays 的方式，把基本类型的值或者数组类型上的相关方法组织起来。我们可以通过java.util.Collections的方式，把实现特定接口的对象上的静态方法组织起来。最后还可以了利用这种类把final类上的方法组织起来，以取代扩展该类的做法。
  这样的工具类(utility calss)不希望被实例化，实例对它没有任何意义。然而在缺少显示构造器的情况下，编译器会自动提供一个公有的、无参的缺省构造器(default constructor)。对于用户而言，这个构造器与其他的构造器没有任何区别。在已发行的API中常常可以看到一些被无意识地实例化的类。
  企图通过将类做成抽象类来强化该类不可被实例化，这是行不通的。该类可以被子类化。并且该子类也可以被实例化。这样做甚至会误导用户，以为这种类是专门为了继承而设计的。然而，有一些简单的习惯用法可以确保类不可被实例化。由于只有当类不包含显示的构造器时，编译器才会生成缺省构造器，因此我们只要让这个类包含私有构造器，它就不能被实例化了：

/**
 * @author: Hashub小晖
 * @WeChat: NGSHMVP
 * @Date: 2018/10/2 20:25
 * @function:Noninstantiable utility class
 */
public class UtilityClass
{
    //Suppress default constructor for noninstantiabllity
    private UtilityClass()
    {
        throw new AssertionError();
    }

    ///Remaindr omitted
}

由于显示的构造器私有，所以不可以在该类的外部访问它。AssertionError不是必须的，但是它可以避免不小心在类的内部调用构造器。它保证该类在任何情况下都不会被实例化。这种习惯用法有点违背直觉，好像构造器就是专门设计成不能被调用一样。因此，明智的做法就是在代码中增加一条注释，如上所示。
  =这种习惯用法也有副作用，它使得一个类不能被子类化。所有的构造器必须显式或隐式地调用超类构造器，在这种情况下，子类就没有可访问的超类构造器可用了。