1.Consider static factory method instead of constructor
大意为考虑使用静态的工厂方法而不是构造器
用户在获得类它本身的实例的时候，通常会想到的就是使用public的构造器，但是一个类可以提供一个public的工厂方法。
这种工厂方法简化了返回该类实例的静态方法
文章给出了一个例子
public static Boolean valueOf(boolean b) {
return b ? Boolean.TRUE : Boolean.FALSE;
}
需要注意的是，这里的工厂方法并不是设计模式里面所讲的工厂方法
这种工厂方法有优缺点，先说说优点
首先是工厂方法和构造器不一样，它们拥有名字
如果构造方法没有一堆参数，那么有着不同名字的工厂方法更加容易去返回相应描述的对象同时也使得代码更加容易阅读
举个例子，构造方法BigInteger(int, int, Random)，返回一个概率性的BigInteger，我们可以用一个工厂方法 BigInteger.probablePrime代替掉，而且提高了可读性
一个类在给定的标志（参数列表）下拥有唯一一个构造方法
我们可以通过Java的方法重载实现多个不同参数列表的构造方法，这是实在不是一个好的主意
用记住参数列表的方法来记住不同的构造方法，最后只会因为使用错的参数列表而引起错误，参数列表太难去记忆了
而且当别人阅读你的代码的时候并不知道你的构造器的不同，除非他去翻看你的类文档
那么工厂方法拥有自己的名字，静态的工厂方法就没有我们前面所说的限制了
所以，当有需要多种构造方法的时候，去创建静态工厂方法，然后用特殊名字来区分它们是一种更加优的策略
第二个优点是，当这些静态工厂方法被使用的时候，并不需要创建一个新的对象
这意味着我们可以重复使用之前的构造出来的对象，重复去使用这些实例，避免了没有必要的对象的产生
之前我们所举得例子Boolean.valueOf(boolean)方法表现了这个特性，它没有创建对象，这种特性类似于（Flyweight pattern享元模式），那么当我们需要重复使用某个相等的对象的时候，并且调用起来可能代价很大的情况下，我们使用工厂模式可以得到表现上很大的提升
使用静态工厂方法，可以对这些你所需要的实例有着严格的控制，不会造成资源浪费等问题，这被称为“实例控制”，这样的实例控制使得一个类可以是单例模式（Singleton）或者 非实例化模式（noninstantiable），当然，也可以是一个一成不变的类（Immutable class），保证了不可能同时存在两个相等的实例，用代码来解释的话就是说， a.equals(b)等价于 当且仅当a==b，也就是你使用“==”来判断两个对象是否相等在工厂方法模式下是可行，Enum（枚举）的类型就提供了这个保证
第三个优点是，静态工厂方法可以返回任意它们返回类型的子类型（非子类而是子类型，类似数据类型和子数据类型的意思）的对象，这在选择返回对象的类方面会给你更强大的灵活性
一个有着这样灵活性的应用就是一个可以返回对象并且不用使他们的类是public的API
隐藏了复杂的API中的实现类，这种特性将自身化为一种接口为基础的框架（interfa-based frameworks），这里的接口提供了静态工厂方法自然的返回类型，接口是不能有静态方法的，故Type接口的静态方法被放在一个非实例化模式（noninstantiable）类里面，叫做Types
举个例子，Java里面的Collections Framework有着32个collection接口的便利的实现，提供unmodifiable collections, synchronized collections等等，所有的这些实现几乎都是利用在非实例化类（java.util.Collections）中的静态工厂方法，返回的对象的类都是非public的
如果这个Collection Framework API的实现都用了分离开来的public类，那样其体积会大得多
使用这样的静态工厂方法呢使得用户利用接口而不是实现化的类来引用返回对象
当然，使用静态工厂方法不仅仅能够使得返回的类是非public的，还能根据静态工厂的参数不同来使调用不同，任意声明了返回类型的子类型的类是被允许的，这样增强了软件的稳定性和表现
Java中的EnumSet，在1.5版本中，没有构造器，只有许多的静态工厂，它们返回两，种实现的一种，取决于enum类型的大小，如果是64或者更少的元素，正如大多数情况下的枚举，静态工厂会返回一个RegularEnumSet的实例，受一个简单的long类型支持，如果超过64了，就返回一个JumboEnumSet的实例，收一个long的array类型支持
第四个优点是，使用静态工厂方法可以减少创建参数化类型的实例的赘冗，不幸运的是，你必须确定类型参数当你调用参数化类的构造器即使这些参数类型从上下文来看是明显的，这特别地需要你去提供两次参数类型才能成功，举个例子
Map<String, List<String>> m = new HashMap<String, List<String>>();
这样的类型参数一增加看上去又长又复杂，使用静态工厂，编译器可以帮你整理那些参数，这就是我们所知的类型推断（Type Inference），我们可以使用静态工厂在HashMap上，假设HashMap提供下面这个静态工厂
public static <K, V> HashMap<K, V> newInstance() {
return new HashMap<K, V>();
}
然后创建起来就简单了许多
Map<String, List<String>> m = HashMap.newInstance();
目前来看Java还没有进行工厂的加入，可能有一天这种参数推断会和在方法调用一样在构造器上表现良好
遗憾的是，1.6版本标准的Collection implementation像HashMap一样并没有工厂方法，你可以自己创建工具类来实现，更加重要的是，你可以自己提供自己的参数化类的静态工厂
我们来说说它的缺点，最主要的缺点就是这样的一个提供静态工厂的没有public或者protected的构造方法的类并不能被子类化，非public并且被一个public的静态工厂所返回的类也有一样的情况
举个例子，我们不可能去子类化任意的拥有便利的实现的类在Collection Framework里面，可以说这能够是伪装起来的一个好事，正如它鼓励程序员去使用组合而不是继承
第二个缺点是，静态工厂方法不容易和其他的静态方法区分，它们并没有在API文档中如同构造器一样，所以可能去解决怎样去初始化一个提供静态工厂方法而不是构造器的类的时候会有点困难，javadoc工具可能有一天可以关注一下这些静态工厂的方法，为了减少这种区分上的问题，我们可以自己坚持通用命名转换。
比如valueOf，of，getInstance，newInstance，getType
总结，静态工厂方法和public构造器都有它们的用处，都有它们的优缺点，通常来说静态工厂更推荐，所以需要避免本能的提供public构造方法没不是优先考虑一下静态工厂
