我应该总是使用静态工厂方法而不是构造函数吗？答案

【问题标题】：Should I always use static factory methods instead of constructors?我应该总是使用静态工厂方法而不是构造函数吗？
【发布时间】：2012-03-16 05:48:04
【问题描述】：

阅读Effective Java，似乎使用静态工厂方法有很多优点，而缺点很少。通过静态工厂方法，我特别指以下

public class MyClass {    
  private MyClass() { ... };  

  public static MyClass getInstance() {
    return new A();
  }    
}

来自 Effective Java：

请注意，静态工厂方法与设计模式中的工厂方法模式不同 [Gamma95, p. 107]。此项中描述的静态工厂方法在设计模式中没有直接等效方法。

现在最好始终遵循这种做法，还是只偶尔遵循？

如果是什么时候？

这样做是不是有点矫枉过正？

【问题讨论】：

矫枉过正。只有你自己可以判断。一般来说，我会告诫您不要盲目地遵循任何已获得的智慧。你通常会发现所有用来对冲原始陈述的原始限定都被遗忘了，只剩下规则，通常没有人真正知道为什么。
在这种情况下，我们很幸运，因为原始文本在有效 Java 条款 1 中得到了保留。但我不确定我对此的解释是否正确。
我会说这通常是矫枉过正，除非您有特定的原因想要隐藏正在创建的实际类型，这基本上是当您想要使用工厂模式时。我建议在大多数情况下并非如此。想想如果你不能构造一个字符串或线程，生活会是什么样子。

标签： java oop

【解决方案1】：

一般来说，构造函数比工厂简单，所以这是选择构造函数而不是工厂的主要原因。当情况需要时使用工厂，没有“默认”。你应该做最简单的事情来解决你的问题，而且大多数时候这将是构造函数。

【讨论】：

我喜欢你的推理（奥卡姆剃刀），但是我想知道将构造函数公开是否可以稍后再咬。一旦它的公开，它就不能再被私有化，而不会破坏使用构造函数的现有代码的风险。这意味着稍后改造静态工厂方法可能会很痛苦。另外我想也可能存在线程安全问题。我不是要质疑你的答案，但我只是想知道是否还有比这更多的内容？
这是一个判断调用区域，但一个常见的问题是开发人员倾向于过度设计他们的代码。虽然您确实应该提前考虑，但您应该考虑有多大可能需要进行此类更改。然后你必须做出判断。总的来说，我仍然会说越简单越好。这本质上是 YAGNI 的一个论点：en.wikipedia.org/wiki/You_ain't_gonna_need_it
这是一个很好的观点。我想知道如何在一方面避免过度设计和良好封装之间取得平衡，即尽量减少类和成员的可访问性？也就是说，构造函数总是可以公开的，但是一旦公开，它就必须公开直到时间结束。
这很困难，我认为它需要大量的经验。它确实取决于每个案例，您需要对其进行分析。它可以追溯到您认为需要某些东西的可能性。你应该看看你的“猜测”是如何产生的，并在未来做出相应的调整。

【解决方案2】：

工厂方法从使用对象的代码中抽象出对象的创建和配置。

如果一切都取决于对象的创建和初始化所涉及的复杂性。如果它们很简单，则无需使用工厂模式。

如果它有点复杂（在使用之前涉及很多初始化步骤），最好使用工厂模式。

【讨论】：