Question

我正在调查Guice，我最近一直在阅读它的文档。

阅读motivation部分我不了解工厂部分，为什么他们这样命名。对我来说，工厂只是实现类的包装器，他们希望在调用getInstance（）之后返回它。

public class CreditCardProcessorFactory {

  private static CreditCardProcessor instance;

  public static void setInstance(CreditCardProcessor creditCardProcessor) {
    instance = creditCardProcessor;
  }

  public static CreditCardProcessor getInstance() {
    if (instance == null) {
      throw new IllegalStateException("CreditCardProcessorFactory not initialized. "
          + "Did you forget to call CreditCardProcessor.setInstance() ?");
    }

    return instance;
  }
}

如果它既不是抽象工厂也不是工厂方法（至少它们最初由GoF定义），为什么他们称之为工厂？或者我错过了什么？

感谢。

编辑：如果有人想出更好的头衔，我会很乐意改变它。

Answer 1

我使用了一种类似的模式，在这种模式中，代码可以被赋予不同的类，以根据其上下文执行某些操作。例如，如果CreditCardProcessor是接口或抽象类，则高级代码希望通过创建它并将其传递给CreditCardProcessorFactory来设置要使用的实现。使用代码只是得到一个CreditCardProcessor而不关心它是什么实现。

这与Factory模式有相似之处，因为你得到的是一个CreditCardProcessor，而不关心你有哪些实现;你只是没有传递任何参数到工厂方法（在这种情况下命名错误的getInstance（））。您获得的实现取决于其他代码设置的内容，而不是您指定的参数。在这种情况下，我甚至可能已经调用了我实现工厂的类。

getInstance（）和setInstance（）是错误的名称，因为它们会让你想到一个Singleton。我本可以使用getCreditCardProcessor和setCreditCardProcessor。

Answer 2

我是这份文档的作者。我把它称为工厂，以便与DocumentBuilderFactory和TransformerFactory等JDK类保持一致。如果从未调用setInstance（），则示例的先前版本返回默认实现：

  public static CreditCardProcessor getInstance() {
    if (instance == null) {
      return new SquareCreditCardProcessor();
    }
    return instance;
  }

我更改了它以避免从工厂到其实现的编译时依赖性。该类具有setInstance（），因为它比JDK用于在运行时选择实现的系统属性更简单。

由于我们试图激励依赖注入，显示一个功能齐全的工厂似乎是不公平的，即使这意味着对原始GoF模式不忠。

Answer 3

这可能只是一种简化。 Java有一堆工厂类，如下所示：

Foo newFoo = FooFactory.getInstance().makeFoo();

......实质上，与示例中的内容大致相同。是的，Guice示例使用静态方法而不是singletong方法中的方法，但我们已经知道singletons are little more than a very roundabout way of making static methods and fields。我认为他们只是快速做了一些事情，以显示代码看起来有多糟糕，并且他们并不真正关心遵守GoF模式的正典。

Answer 4

Ya但是没有任何实例化的预防（私有构造函数），它也不完全遵循单例模式。

让它在这里完整代码...... ：）

对这家工厂感到困惑，因为它看起来不像抽象工厂或工厂方法

4 个答案: