本章的主题是创建和销毁对象：何时以及如何创建对象，何时以及如何避免创建对象，如何确保它们能够适时地销毁，以及如何管理对象销毁之前必须进行的各种清理动作。
注意：静态工厂方法与设计模式中的工厂方法模式不同。本条目中所指的静态工厂方法并不直接对应设计模式中的工厂方法。
[toc]
类可以通过静态工厂方法来提供它的客户端，而不是通过构造器。这么做有以下几大优势：
它们有名称。
当一个类需要多个带有相同签名的构造器时，就用静态工厂方法代替构造器，并且慎重地选择名称以便突出它们之间的区别不必每次调用它们的时候都创建一个对象。
能够为重复的调用返回相同的对象，有助于类总能严格控制在某个时刻哪些实例应该存在。这种类被称作实例受控类（instance-controlled）。编写实例受控类有几个原因：确保它是一个Singleton（见第三条 单例）或者 是不可实例化的（见第4条）。还使得不可变的类（见第15条）可以确保不会存在两个相等的实例，即当且仅当 a==b 的时候才有 a.equals(b) 为 true，可以提升性能【书这里单词错了】它们可以返回原返回类型的任何子类型的对象。
这样我们在选择返回对象的类时就有了更大的灵活性。这种灵活性的一种应用是，API 可以返回对象，同时又不会使对象的类变成公有的。以这种方式隐藏实现类会使API变得非常简介。这项技术适用于基于接口的框架（interface-based-framework，见第18条 ），在这种框架中，接口为静态工厂方法提供了 自然返回类型。
自然返回类型(natural return types)
可能有人会对自然返回类型产生疑问，以下是加粗文字的英文原版：
where interfaces provide natural return types for static factory methods.
个人的理解是：此框架静态工厂方法返回的类型都是接口类型，也就是接口类型为静态工厂方法提供了返回类型，这点我会结合下面的 java.util.Collections 源码（JDK 1.8）说明。
在此框架中，接口为静态工厂方法提供了自然返回类型。接口不能有静态方法，按照惯例，接口 Type 的静态工厂方法被放在一个名为Types的不可实例化类（见第4条）中。
书中提了一个 Java Collections Framework 的例子，这里我结合 Collections 的源码，整理一下思路。
首先书中说 Java Collections Framework 的便利实现，几乎都通过静态工厂方法在一个不可实例化的类（java.util.Collections）中导出。所有返回对象的类都是非公有的。
构造器私有，不可实例。
返回对象的类为非公有类（静态私有），此框架静态工厂方法返回的类型都是接口类型。
比导出独立公有类的那种实现方式要小得多，这不仅仅是指API上的减少，也是概念上的减少。
用户 知道，被返回的对象是由相关的接口精确指定的，所以它们不需要阅读有关的类文档。使用这种静态工厂方法时，甚至要求 客户端 通过制定接口来引用被返回的对象，而不是通过它的实现类来引用被返回的对象，这是一种良好的习惯（见第52条）【客户与用户的差别在第一章有说明】
公有的静态工厂方法返回的对象类不仅可以是非公有的，还可以随着每次调用时的方法参数不同而变化，只要返回的是已声明返回类型的子类型，都是允许的，为了提升软件的可维护性和性能，返回对象的类也可能随着发行版本的不同而不同。
书中提到的 java.util.EnumSet 类，没有构造器（抽象类），可结合阅读，截图（JDK1.8）如下：
客户端永远不知道也不关心他们从工厂方法种得到的对象的类；只关系它是所需类的某个子类即可。
服务提供者框架
因为篇幅原因，这里以 JDBC 简要说明，详细内容可自行 google 。
此框架由四个组件组成，前三个为重要组件，最后一个为可选组件。
- 服务接口（Service Interface）：提供者（Mysql Oracle）实现的;
- 提供者注册 API（Provider Registration API）：系统用于注册实现，使客户端访问；
- 服务访问 API（Service access API）：客户端用来获取服务实例；
- 服务提供者接口（Service Provider Interface）：提供者负责创建其服务实现的实例；
对照 JDBC
- 服务接口： Connection
- 提供者注册API： DriverManager.registerDriver
- 服务访问API： DriverManager.getConnection
- 服务提供者接口： Driver
其中，Connection 只是一个接口（规范），各大数据库厂商【提供者】根据此接口编写实现类，让 DriverManager.registerDriver 注册，使得客户端可以使用 DriverManager.getConnection 获得实例，如果有提供服务提供者接口 Driver 则由其创建服务实现的实例，如果没有就按照类名注册，并通过反射实例化。
适配器模式（adapter）：
适配器模式的个人理解：实现旧接口，组合所需类，在旧接口的方法中调用所需类的方法。
此模式除了上述3个优点外，还增加了第四个优点：
在构建参数化类型实例的时候，它们使代码变得更加简洁
在调用参数化类的构造器时，即使类型参数很明显，也必须指明。这通常要求你链接两次提供类型的参数：
Map< String , List< String > > m =
new HashMap< String , List< String > >();
而有了静态工厂方法，编译器旧可以替你找到类型参数。这被称为类型推导（type inference）【在泛型章节也有提到】。
public static <K , V> HashMap <K , V> newInstance ( ) {
return new HashMap<K , V> ( ) ;
}
Map<String , List < String > > m = HashMap.newInstance ( ) ;
总有一天，Java 将能够在构造器调用以及方法调用中执行这种类型推导，但到发行版 1.6 为止暂时还不能这么做【JDK 1.8 也没有】。标准的 Map 实现如 HashMap 并没有工厂方法，但是可以将这些方法放入你自己的工具箱。
静态工厂方法的主要缺点：
类如果不含公有的或者受保护的构造器，就不能被子类化。
鼓励程序员使用复合（composition），而不是继承（见第16条）它们与其他的静态方法 实际上没有任何区别。
在 API 文档中，它们没有像构造器那样被明确的标识出来，你可以通过在 类 或者 接口 注释中关注静态工厂，并遵守标准的命名习惯，也可以弥补这一劣势。
静态工厂方法的一些惯用名称：
valueOf：不太严格的讲，该方法返回的实例与它的参数具有相同的值。这样的静态工厂方法实际上是类型转换方法。
of：valueOf 的一种更为简介的替代，在 EnumSet（见第32条） 中使用并流行起来。
getInstance：返回的实例是通过方法的参数来描述的，但是不能够说与参数具有同样是值。对于 Singleton 【单例】来说，该方法没有参数，并返回唯一的实例。
newInstance：像 getInstance 一样，但 newInstance 能够确保返回的每个实例都与所有其他不同。
getType：像 getInstance 一样，但是在工厂方法处于不同的类中的时候使用。Type 标识工厂方法返回的类型对象【getInteger、getLong】。
newType：像 newInstance 一样，但是在工厂方法处于不同的类中的时候使用。Type 标识工厂方法返回的类型对象【newInteger、newLong】。
简而言之，静态工厂方法 和 公有构造器 各有用处，我们需要理解它们各自的长处。静态工厂通常更加合适，因此切记第一反应就是提供公有的构造器，而不先考虑静态工厂。
