我们是否需要更喜欢构造函数而不是静态工厂方法？如果是的话，什么时候？

我一直在阅读有效的Java by 约书亚·布洛赫到目前为止，它确实名副其实。第一项就提供了令人信服的理由静态工厂方法 over 构造函数。以至于我开始质疑那些好的旧构造函数的有效性:)。

本书的优点/缺点总结如下：

优点：

1. 他们有名字！
2. 我们拥有全面的实例控制（单例、性能等）
3. 他们可以返回子类型/接口
4. 编译器可以提供类型推断

缺点：

1. 私有类不能被子类化
2. 它们不像构造函数那样在文档中脱颖而出

第一个缺点实际上可以是一件好事（正如书中提到的）。我认为第二个只是一个小缺点，可以通过即将发布的 java 版本（javadoc 等注释）轻松解决。

看起来，最终工厂方法几乎拥有构造函数的所有优点，还有更多的优点，并且没有真正的缺点！

所以，我的问题基本上分为三个部分：

1. 默认情况下始终使用静态工厂方法而不是构造函数是一个好的做法吗？
2. 使用构造函数是否合理？
3. 为什么面向对象语言不为工厂提供语言级支持？

Note:有两个类似的问题：何时使用构造函数以及何时使用 getInstance() 方法（静态工厂方法）？ https://stackoverflow.com/q/3169372/1077737 and 对象的创建：构造函数或静态工厂方法 https://stackoverflow.com/q/4617311/1077737。然而，答案要么只是提供上面的列表，要么重申我已经知道的静态工厂方法背后的基本原理。

静态工厂最终仍然需要调用构造函数。您可以将大部分功能移至静态工厂中，但无法避免使用构造函数。

另一方面，对于简单的情况，您可以只使用构造函数而不使用静态工厂。

构造函数是设置最终字段的唯一方法，恕我直言，这比非最终字段更可取。

您可以在子类中使用构造函数。您不能对子类使用静态工厂。

如果您有一个良好的依赖项注入框架来构建组件的依赖项，您可能会发现静态工厂不会添加太多内容。