静态工厂方法缺点
静态工厂方法的主要缺点在于，类如果不含有公有的或者受保护的构造器，就不能被子类化。对于公有的静态工厂所返回的非公有类，也同样如此。例如，要想将CollectionsFramework中的任何方便的实现类子类化，这是不可能的。但是这样也许会因祸得福，因为它鼓励程序员使用复合（composition），而不是继承。
静态工厂方法的第二个缺点在于，它们与其他的静态方法实际上没有任何区别。在API文档中，它们没有像构造器那样在API文档中明确标识出来，因此，对于提供了静态工厂方法而不是构造器的类来说，要想查明如何实例化一个类，这是非常困难的。同时，你通过在类或者接口注释中关注静态工厂，并遵守标准的命名习惯，也可以弥补这一劣势。下面是静态工厂方法的一些惯用名称：
常用命名规则
valueOf —— 不太严格地讲，该方法返回的实例与它的参数具有相同的值。这样的静态工厂方法实际上是类型转化方法。
of —— valueOf 的一种更为简洁的替代，在 EnumSet （见第32条）中使用并流行起来。
getInstance —— 返回的实例是通过方法的参数来描述的，但是不能够说与参数具有同样的值。对于 Singleton 来说，该方法没有参数，并返回唯一的实例。
newInstance —— 像 getInstance 一样，但 newInstance 能够确保返回的每个实例都与所有其他实例不同。
getType —— 像 getInstance 一样，但是在工厂方法处于不同的类中的时候使用。Type表示工厂方法所返回的对象类型。
newType —— 像 newInstance 一样，但是在工厂方法处于不同的类中的时候使用。
Type表示工厂方法所返回的对象类型。
第1条：考虑用静态工厂方法代替构造器
简而言之，静态工厂方法和公有构造器都各有用处，我们需要理解它们各自的长处。静态工厂通常更加合适，因此切忌第一反应就是提供公有的构造器，而不先考虑静态工厂。