《Effective Java 中文版 第二版》第二章 第1条：

本章的主题是创建和销毁对象：何时以及如何创建对象，何时以及如何避免创建对象，如何确保它们能够适时地销毁，以及如何管理对象销毁之前必须进行的各种清理动作。

---

注意：静态工厂方法与设计模式中的工厂方法模式不同。本条目中所指的静态工厂方法并不直接对应设计模式中的工厂方法。

[toc]

类可以通过静态工厂方法来提供它的客户端，而不是通过构造器。这么做有以下几大优势：

1. 它们有名称。
   当一个类需要多个带有相同签名的构造器时，就用静态工厂方法代替构造器，并且慎重地选择名称以便突出它们之间的区别

2. 不必每次调用它们的时候都创建一个对象。
   能够为重复的调用返回相同的对象，有助于类总能严格控制在某个时刻哪些实例应该存在。这种类被称作实例受控类（instance-controlled）。编写实例受控类有几个原因：确保它是一个Singleton（见第三条 单例）或者 是不可实例化的（见第4条）。还使得不可变的类（见第15条）可以确保不会存在两个相等的实例，即当且仅当 a==b 的时候才有 a.equals(b) 为 true，可以提升性能【书这里单词错了】

3. 它们可以返回原返回类型的任何子类型的对象。
   这样我们在选择返回对象的类时就有了更大的灵活性。这种灵活性的一种应用是，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）中导出。所有返回对象的类都是非公有的。

java.util.Collections 类

构造器私有，不可实例。

Collections 类中的 unmodifiableMap 方法

返回对象的类为非公有类（静态私有），此框架静态工厂方法返回的类型都是接口类型。

比导出独立公有类的那种实现方式要小得多，这不仅仅是指API上的减少，也是概念上的减少。
用户 知道，被返回的对象是由相关的接口精确指定的，所以它们不需要阅读有关的类文档。使用这种静态工厂方法时，甚至要求 客户端 通过制定接口来引用被返回的对象，而不是通过它的实现类来引用被返回的对象，这是一种良好的习惯（见第52条）【客户与用户的差别在第一章有说明】

公有的静态工厂方法返回的对象类不仅可以是非公有的，还可以随着每次调用时的方法参数不同而变化，只要返回的是已声明返回类型的子类型，都是允许的，为了提升软件的可维护性和性能，返回对象的类也可能随着发行版本的不同而不同。

书中提到的 java.util.EnumSet 类，没有构造器（抽象类），可结合阅读，截图（JDK1.8）如下：

java.util.EnumSet 类

客户端永远不知道也不关心他们从工厂方法种得到的对象的类；只关系它是所需类的某个子类即可。

---

服务提供者框架

因为篇幅原因，这里以 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】。

简而言之，静态工厂方法 和 公有构造器 各有用处，我们需要理解它们各自的长处。静态工厂通常更加合适，因此切记第一反应就是提供公有的构造器，而不先考虑静态工厂。