对比静态工厂
静态工厂方法很容易让人想到设计模式的静态工厂，也叫简单工厂，作者说两者不同，我认为这两者仅是从概念上来讲有区别，从技术的角度来讲没有区别
简单来说，其区别体现在：静态工厂方法所在的类的意义是具体的，并且这个方法只创造与这个方法所在类直接相关的对象。而静态工厂的概念与静态工厂方法并不等同，静态工厂是更宽泛的概念，其实现包含了静态工厂方法，静态工厂里的静态工厂方法生产的不是工厂本身，是工厂里的产品，与其所在的类间接关联。
技术上没有区别，这两者的代码结构是一致的，且静态工厂方法里可以使用静态工厂来获得结果，静态工厂也可以使用产品的静态工厂方法。静态工厂方法的优点静态工厂也都可以有。
对比构造方法
- 优势方面
静态工厂方法与构造方法相比，不同的地方在于：
- 静态工厂方法可以有自定义方法名，而构造方法必须等同于类名
- 静态工厂方法可以自定义返回值，而构造方法可以间接等同于只能返回自己的实例
纵观作者总结的5大好处：
- 可读性强，因为可以任意命名，还可以用于实现多构造方法
- 构造方法只要调用就会产生一个对象，但静态工厂方法返回的可以不是新创建的
- 可以返回当前类的任意子类对象，常用于接口
- 每次调用都可以根据参数返回不同的类，EnumSet的例子，会根据需要的大小返回不同的EnumSet
- 返回的对象所属的类，在写代码的时候可以不存在。
实际就是这两个方面，灵活的方法名和灵活的返回值带来的好处。
静态工厂方法的第一类好处是说有意义的方法名提高了代码可读性，这不是静态工厂方法独有的，是编程世界里所有的普通方法都有的好处。这启发我们在写代码的过程中无论你是面向过程也好，面向对象也好，面向接口，还是面向其它XXX也好，多写方法，多取有意义的方法名，这是提升代码可读性非常有效的方式，比很多开发只知道写注释有用多了。
第二类关于返回值的好处说了很多条，都很有用，观念上具有指导作用，但在现在的Java世界，一定有必要按照这种方法去实践吗？可能很多情况下都没有必要了。
比如第二点，其实主要应用就是一些缓存啊，单例之类的场景。就拿单例来说，使用静态工厂方法实现懒汉式单例，你还需要解决线程安全的问题，解决代码编译重排的问题，解决这个问题复杂吗？不复杂，有必要吗？可以没必要，使用Spring Bean，完全可以抛弃这么原始的做法。
后面几点好处比较常用的场景基本都是在使用接口的情况下，静态工厂方法可以返回接口不同的实现，那有了Spring这么强大的IoC框架，静态工厂方法作为学习，理解思路可以，实现业务的时候其实有更好的工具。
特别提一下第5点，这个着实理解了很久，最后我觉得作者可能是从编译class的角度在说，就是你这个方法可以返回一个编译时不存在，只出现在运行时的实现类。从这个角度出发，我想到两类场景，一类是通过反射在运行时获得真正的对象。典型的应用比如Class.forName。还有一类场景是使用动态配置的场景，比如我创造一个map，在运行里会加载DB里的动态配置，静态工厂方法可以在写代码的时候不需要这个具体的配置类存在，再扯远一些比如枚举，其实返回的枚举类也是可以不存在的，这些场景不一定典型，但我觉得也符合这个好处。
总结一下，静态工厂方法有些场景下可以提升代码可读性，可以使用，至于单例或者解耦的场景，我们有更强大的工具可以使用，使用静态工厂方法比较原始，会有很多问题需要去解决。不过，如果用不了强大的工具，那也只能回归原始。带来的启发是，多写方法，多用接口。
- 劣势方面
静态工厂方法当然也有缺点：
- 使用静态工厂方法通常需要把构造方法私有化，因此不能被子类化。
- 静态工厂方法比较隐晦，不易被发现，一般可以采用约定的名称来命名使其容易被发现。
都是小问题。在不容易被发现这点后提了一些静态工厂方法的约定，我倒觉得有点意思。像from，of，instance这些词很有意义吗？我觉得并不，那岂不是不符合静态工厂方法可以增加可读性的特点？对，胡乱使用的情况下我觉得还不如回归到构造方法。但注意，作者实际上补充了一大堆这些命名背后的含义，也就是说这些命名需要基于约定。达成约定后这些命名含义就具体了。然而我觉得这件事不简单，你比如说Java官方的Optional.of()，并不符合作者要求的of用于聚合的情景。
那到底还用不用，是不是鸡肋呢？我支持用，原因是这样写出来的代码更美观，这可能是第6个优点：赏心悦目。
