静态工厂vs单身工厂

在我的某些代码中，我有一个类似于以下内容的静态工厂：

public class SomeFactory {

    // Static class
    private SomeFactory() {...}

    public static Foo createFoo() {...}

    public static Foo createFooerFoo() {...}
}

在代码审查期间，建议将其作为一个单例并注入。因此，它应如下所示：

public class SomeFactory {

    public SomeFactory() {}

    public Foo createFoo() {...}

    public Foo createFooerFoo() {...}
}

需要强调的几件事：

• 两个工厂都是无状态的。
• 方法之间的唯一区别是它们的范围（实例与静态）。实现是相同的。
• Foo是没有接口的bean。

我要静态化的参数是：

• 该类是无状态的，因此不需要实例化
• 能够调用静态方法比必须实例化工厂似乎更自然。

工厂作为单例的参数是：

• 注入一切都很好
• 尽管工厂是无状态的，但使用注入进行测试还是比较容易的（易于模拟）
• 测试消费者时应该嘲笑它

我对单例方法有一些严重的问题，因为它似乎表明任何方法都不应该是静态的。它还似乎暗示StringUtils应该包装和注入诸如此类的实用程序，这似乎很愚蠢。最后，这意味着我需要在某个时候模拟工厂，这似乎不正确。我想不起来何时需要模拟工厂。

社区对此有何看法？尽管我不喜欢单例方法，但我似乎对此没有强烈的反对意见。

为什么要将工厂与它创建的对象类型分开？

public class Foo {

    // Private constructor
    private Foo(...) {...}

    public static Foo of(...) { return new Foo(...); }
}

这就是约书亚·布洛赫（Joshua Bloch）在其书“有效Java”第5页上描述为项目1的内容。Java非常详细，无需添加额外的类，单例和其他功能。在某些情况下，使用单独的工厂类是有意义的，但它们之间相距甚远。

为了解释约书亚·布洛赫（Joshua Bloch）的第1项，与构造函数不同，静态工厂方法可以：

• 具有可以描述特定类型的对象创建的名称（Bloch使用probablePrime（int，int，Random）作为示例）
• 返回一个现有的对象（想想：flyweight）
• 返回原始类的子类型或它实现的接口
• 减少冗长（指定类型参数-例如参见Bloch）

缺点：

• 没有公共或受保护的构造函数的类不能被子类化（但是您可以使用受保护的构造函数和/或第16项：优先考虑继承而不是继承）
• 静态工厂方法不会与其他静态方法脱颖而出（使用标准名称，如of（）或valueOf（））

确实，您应该将Bloch的书交给代码审阅者，看看你们两个是否同意Bloch的风格。

就在我脑海中，这是Java中的一些静态问题：

• 静态方法不是OOP的“规则”所扮演的角色。就我所知，您不能强迫一个类实现特定的静态方法。因此，不能有多个类使用相同的签名实现相同的静态方法集。所以，你不得不拥有一个不管它是你正在做的。您也不能真正地继承静态类。因此没有多态性，等等。

• 由于方法不是对象，因此静态方法无法传递，也无法使用（除非进行大量的样板代码编写），除非通过硬链接到它们的代码进行，这使客户端代码高度耦合的。（公平地说，这不仅是静态的错误）。

• 静态字段与全局字段非常相似

您提到：

我对单例方法有一些严重的问题，因为它似乎表明任何方法都不应该是静态的。似乎还建议应该包装并注入诸如StringUtils之类的实用程序，这似乎很愚蠢。最后，这意味着我需要在某个时候模拟工厂，这似乎不正确。我想不起来何时需要模拟工厂。

这使我好奇地问你：

• 您认为静态方法的优点是什么？
• 您认为StringUtils设计和实施正确吗？
• 您为什么认为您永远不需要嘲笑工厂？

我认为您正在构建的应用程序必须相当简单，否则您的生命周期就相对较早。我能想到的唯一唯一的情况是，如果您设法将了解工厂的代码的其他部分限制在一两个地方，那么您的静态变量就不会遇到问题。

想象一下您的应用程序在不断发展，现在在某些情况下您需要产生一个FooBar（Foo的子类）。现在，您需要遍历代码中所有与自己有关的地方，SomeFactory并编写某种逻辑来查看someCondition和调用SomeFactoryor SomeOtherFactory。实际上，看看您的示例代码，情况比这更糟。您打算只在创建不同的Foos的方法之间添加方法，并且所有客户端代码都必须在确定要创建哪个Foo之前​​检查条件。这意味着所有客户都需要对Factory的工作方式有深入的了解，并且每当需要（或删除！）新Foo时，他们都需要进行更改。

现在想象一下，如果您刚刚创建了一个IFooFactory，则会生成一个IFoo。现在，产生不同的子类甚至是完全不同的实现是孩子的事—您只需在链的更高层输入正确的IFooFactory，然后当客户端获取它时，它将调用gimmeAFoo()并将获得正确的foo，因为它获得了正确的Factory 。

您可能想知道这在生产代码中如何发挥作用。为了给您一个我正在开发的代码库中的示例，经过一年多的项目扩展后，该示例开始趋于平稳。我有很多工厂用来创建Question数据对象（它们类似于Presentation Models）。我有一个QuestionFactoryMap基本上是一个哈希，用于查找何时使用哪个问题工厂。因此，为了创建一个提出不同问题的应用程序，我在地图中放置了不同的工厂。

可以在“说明”或“练习”（都实现IContentBlock）中提出问题，因此每个问题InstructionsFactory或ExerciseFactory都会获得QuestionFactoryMap的副本。然后，将各种说明和练习工厂移交给ContentBlockBuilder该再次维护何时使用的哈希。然后，当加载XML时，ContentBlockBuilder会从散列中调用Exercise或Instructions工厂，并要求将其提交给createContent()，然后Factory将问题的构建委托给它根据其内部QuestionFactoryMap提取的内容。在每个XML节点与散列中。不幸的是，那东西是BaseQuestion一个IQuestion，但这只是表明，即使您在设计时保持谨慎，也可能犯下会困扰您的错误。

您的肠胃告诉您这些静电会伤害您，并且文献中肯定有很多内容可以支持您的肠胃。您不会因为仅依赖于单元测试而使用依赖注入（这并不是我相信，如果您构建好的代码不会发现自己更多地使用它），您将永远不会迷失，但是静态会完全破坏您的能力快速轻松地修改您的代码。那为什么还要去那里呢？