Effective第三版 中英 | 第二章 创建和销毁对象 | 通过私有构造器强化不可实例化的能力

Effective第三版

前言

大家好，这里是 Rocky 编程日记 ，喜欢后端架构及中间件源码，目前正在阅读 effective-java 书籍。同时也把自己学习该书时的笔记，代码分享出来，供大家学习交流，如若笔记中有不对的地方，那一定是当时我的理解还不够，希望你能及时提出。如果对于该笔记存在很多疑惑，欢迎和我交流讨论，最后也感谢您的阅读，点赞，关注，收藏~

前人述备矣，我只是知识的搬运工，effective 书籍源码均在开源项目 java-diary 中的 code-effective-third 模块中

源代码仓库地址: https://gitee.com/Rocky-BCRJ/java-diary.git

第二章 创建和销毁对象

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

  Occasionally you’ll want to write a class that is just a grouping of static methods and static fields. Such classes have acquired a bad reputation because some people abuse them to avoid thinking in terms of objects, but they do have valid uses. They can be used to group related methods on primitive values or arrays, in the manner of java.lang.Math or java.util.Arrays. They can also be used to group static methods, including factories (Item 1), for objects that implement some interface, in the manner of java.util.Collections. (As of Java 8, you can also put such methods in the interface, assuming it’s yours to modify.) Lastly, such classes can be used to group methods on a final class, since you can’t put them in a subclass.

  有时候你会想要编写一个只包含一组静态方法和静态字段的类。这种类名声很不好，因为有些人为了避免使用面向对象的思维方式而滥用这样的类(some people abuse them to avoid thinking in terms of objects)，但是他们确实有它们特有的用处。我们可以使用这种类，以java.lang.Math或者java.util.Arrays的方式对原始值或数组的相关方法组织起来。它们还可以用于以java.util.Collections的方式，把实现特定接口的对象上的静态方法（包括工厂：第 1 项）组织起来。（从 Java 8 开始，你也可以将这些方法放在接口中，假设它是你自己修改的)。最后，这些类可以用于将final类的方法组织起来，通过这种方式用来取代扩展该类的做法。

  Such utility classes were not designed to be instantiated: an instance would be nonsensical. In the absence of explicit constructors, however, the compiler provides a public, parameterless default constructor. To a user, this constructor is indistinguishable from any other. It is not uncommon to see unintentionally instantiable classes in published APIs.

  这种工具类不希望被实例化，实例化对它没有任何意义。然而，在没有显式构造函数的情况下，编译器会默认提供一个公共的、无参的默认构造函数。对于用户而言，这个构造器与其他构造器没有任何区别。在已发行的 API 中常常可以看到一些被无意识地实例化的类。

  Attempting to enforce noninstantiability by making a class abstract does not work.The class can be subclassed and the subclass instantiated. Furthermore, it misleads the user into thinking the class was designed for inheritance (Item 19). There is, however, a simple idiom to ensure noninstantiability. A default constructor is generated only if a class contains no explicit constructors, so a class can be made noninstantiable by including a private constructor:

  企图通过将该类做成抽象类来强制该类不可被实例化，这是行不通的。该类可以被子类化，并且该子类也可以被实例化。这样做甚至会误导用户，以为这种类是专门为了继承而设计的（第 19 项）。然而，有一些简单的习惯用法可以确保类不可被实例化。由于只有当类不包含显示的构造器时，编译器才会生成缺省的构造器，因此我们只要让这个类包含私有构造器，他就不能被实例化了：

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

  Because the explicit constructor is private, it is inaccessible outside the class. The AssertionError isn’t strictly required, but it provides insurance in case the constructor is accidentally invoked from within the class. It guarantees the class will never be instantiated under any circumstances. This idiom is mildly counterintuitive because the constructor is provided expressly so that it cannot be invoked. It is therefore wise to include a comment, as shown earlier.

  因为显示构造函数是私有的，所以它在类外是不可访问的，AssertionError不是必需的，但是它可以避免不小心在类的内部调用构造器。它保证该类在任何情况下都不会实例化。这种习惯用法有点违背直觉，好像构造器就是专门设计成不能被调用一样。因此明智的做法就是在代码中增加一条注释，如上所示。

  As a side effect, this idiom also prevents the class from being subclassed. All constructors must invoke a superclass constructor, explicitly or implicitly, and a subclass would have no accessible superclass constructor to invoke.

  这种习惯用法也有副作用，它使得一个类不能拥有子类。因为子类的所有构造函数都必须显示或者隐式地调用父类的构造函数，在这种情形下，子类就没有可用的并且可以访问的父类构造器了。