这一节其实也是在说明工厂设计模式的优秀之处，它相对于构造函数的优势在于：
静态工厂方法有名称
比如BigInteger.probablePrime这个静态方法让人一眼就能看出构造的对象可能是素数
可以不在每次调用时都创建一个新对象
可以参考Spring里面创建单例的逻辑，将构建好的实例存在缓存里返回；而我们调用构造函数时总会创建一个新对象。
静态工厂可以返回原类的子类
class A{ // 构造函数只能得到本类的一个对象 public A(){...} // 静态构造方法可以得到A的子类 public static A的子类 XXXFactory(){...} }
此外，Spring源码里的BeanFactory是工厂设计模式很好的实践，有异曲同工之妙~
可以使用静态工厂方法的入参来控制返回的对象类型
例如EnumSet类的静态工厂方法可以根据入参的元素个数来决定返回RegularEnumSet实例还是JumboEnumSet实例
方法返回的对象所属的类，在编写包含该静态工厂方法的类时可以不存在
这个乍一看有点拗口，但实际上说的还是返回值可以是子类，举个例子：JDBC数据库连接API大家肯定都用过吧，里面的Driver，Connection，Statement都是借口，当我们真正使用时其实用的是厂商的实现类，在编写JDBC时，某些数据库可能根本还没有被研发出来，但后来我们都能使用的原因就是数据库厂商做了对接。
聊完了静态工厂方法的优点，我们可以再聊一聊缺点，这样才能更清楚作者为什么提倡我们这样做：
类如果不含有public的或protected的构造器，就不能被子类化。
通俗一点讲就是，静态工厂方法的本质是，通过返回这个函数返回值的子类，实现灵活性。但是由于子类继承父类，子类的构造函数会默认调用父类的无参构造函数，如果没有就需要显示调用同参的父类构造函数，因此如果父类的构造函数不是共有的或者protected那么就无法实例化子类，那么静态工厂方法就没有意义。
不过作者也介绍了这或许可以“因祸得福”，因为这样鼓励程序员使用复合而不是继承
在API文档里，他们没有想构造函数那样被明确标记出来。
在类的注释里将静态工厂标注出来可以解决，并且javadoc日后必定会增加这一块内容。
