（WIP）
===== 1 问题与常规方案 =====
==== 问题 ====
对于某个类，想让客户端能获取它的实例。
==== 常规方案 ====
提供一个公有构造器。
===== 2 推荐方案 =====
提供一个公有的静态工厂方法，它只是一个返回类的实例的静态方法。
下面是一个来自 Boolean 的例子：
<sxh java>
public static Boolean valueOf(boolean b) {
    return b ? Boolean.TRUE : Boolean.FALSE;
}
</sxh>
===== 3 推荐理由 =====
提供静态工厂方法而不是公有的构造器，有几大优势：
  - 它们有名称。更容易理解和使用，客户端代码的可读性更好。
  - 不必在每次调用它们的时候都创建一个新对象。（提升性能；编写实例受控的类）
  - 它们可以返回原返回类型的任何子类型的对象。这样我们在选择返回对象的类时就有了更大的灵活性。（以 java.util.Collections 为例）
  - 在创建参数化类型实例的时候，它们使代码变得更加简洁。
===== 4 缺点与措施 =====
===== 5 其他阅读收获 =====
==== 好习惯 ====
  * 当一个类需要多个带有相同签名的构造器时，就用静态工厂方法代替构造器，并且慎重地选择名称以便突出它们之间的区别。
==== 坏习惯 ====
  * 一个类只能有一个带有指定签名的构造器。编程人员通常知道如何避开这一限制：通过提供两个构造器，它们的参数列表只在参数类型的顺序上有所不同。实际上这并不是个好主意。面对这样的 API，用户永远也记不住该用哪个构造器，结果常常会调用错误的构造器。并且，读到使用了这些构造器的代码时，如果没有参考类的文档，往往不知所云。