Update 04. 使用私有构造方法执行非实例化.md

This commit is contained in:
Joe 2018-12-24 13:39:06 +08:00 committed by GitHub
parent 0f572820f6
commit 4d7dd11551
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -2,11 +2,11 @@
---
偶尔你会想写一个类,它只是一组静态方法和静态属性。 这样的类获得了不好的名声,因为有些人滥用这些类而避免以面向对象方式思考,但是它们确实有着特殊的用途。 它们可以用来按照 `java.lang.Math``java.util.Arrays` 的方式,在基本类型的数值或数组上组织相关的方法。 它们也可以用于将静态方法(包括工厂(条目 1分组用于实现某个接口的对象其方式为 `java.util.Collections`。 (从 Java 8 开始,你也可以将这些方法放在接口中,假如它是你自己修改的。)最后,这样的类可以用于在 final 类上对方法进行分组,因为不能将它们放在子类中。
  偶尔你会想写一个类,它只是一组静态方法和静态属性。 这样的类获得了不好的名声,因为有些人滥用这些类而避免以面向对象方式思考,但是它们确实有着特殊的用途。 它们可以用来按照 `java.lang.Math``java.util.Arrays` 的方式,在基本类型的数值或数组上组织相关的方法。 它们也可以用于将静态方法(包括工厂(条目 1分组用于实现某个接口的对象其方式为 `java.util.Collections`。 (从 Java 8 开始,你也可以将这些方法放在接口中,假如它是你自己修改的。)最后,这样的类可以用于在 final 类上对方法进行分组,因为不能将它们放在子类中。
这样的实用类utility classes不是设计用来被实例化的一个实例是没有意义的。然而在没有显式构造方法的情况下编译器提供了一个公共的、无参的默认构造方法。对于用户来说该构造方法与其他构造方法没有什么区别。在已发布的 API 中经常看到无意识的被实例的类。
  这样的实用类utility classes不是设计用来被实例化的一个实例是没有意义的。然而在没有显式构造方法的情况下编译器提供了一个公共的、无参的默认构造方法。对于用户来说该构造方法与其他构造方法没有什么区别。在已发布的 API 中经常看到无意识的被实例的类。
**试图通过创建抽象类来强制执行非实例化是行不通的。**该类可以被子类化,子类可以被实例化。此外,它误导用户认为该类是为继承而设计的 (条目 19)。不过,有一个简单的方法来确保非实例化。只有当类不包含显式构造方法时,才会生成一个默认构造方法,**因此可以通过包含一个私有构造方法来实现类的非实例化:**
  **试图通过创建抽象类来强制执行非实例化是行不通的。**该类可以被子类化,子类可以被实例化。此外,它误导用户认为该类是为继承而设计的 (条目 19)。不过,有一个简单的方法来确保非实例化。只有当类不包含显式构造方法时,才会生成一个默认构造方法,**因此可以通过包含一个私有构造方法来实现类的非实例化:**
```Java
// Noninstantiable utility class
@ -19,11 +19,6 @@ public class UtilityClass {
}
```
因为显式构造方法是私有的,所以在类之外是不可访问的。`AssertionError` 异常不是严格要求的,但是它提供了一种保证,以防在类中意外地调用构造方法。它保证类在任何情况下都不会被实例化。这个习惯用法有点违反直觉,好像构造方法就是设计成不能调用的一样。因此,如前面所示,添加注释是种明智的做法。
这种习惯有一个副作用,阻止了类的子类化。所有的构造方法都必须显式或隐式地调用父类构造方法,而子类则没有可访问的父类构造方法来调用。
  因为显式构造方法是私有的,所以在类之外是不可访问的。`AssertionError` 异常不是严格要求的,但是它提供了一种保证,以防在类中意外地调用构造方法。它保证类在任何情况下都不会被实例化。这个习惯用法有点违反直觉,好像构造方法就是设计成不能调用的一样。因此,如前面所示,添加注释是种明智的做法。
  这种习惯有一个副作用,阻止了类的子类化。所有的构造方法都必须显式或隐式地调用父类构造方法,而子类则没有可访问的父类构造方法来调用。