将此类称为“工厂”是否令人困惑？

Question

我对工厂的理解是，它封装了所有继承公共抽象类或接口的具体类的实例化。这允许客户端与确定创建哪个具体类的过程分离，这反过来意味着您可以在程序中添加或删除具体类，而无需更改客户端的代码。您可能需要更改工厂，但工厂是“专门构建的”，实际上只有一个原因需要更改——添加/删除了一个具体的类。

我已经构建了一些实际上封装了对象实例化的类，但出于不同的原因：对象很难实例化。目前，我将这些类称为“工厂”，但我担心这可能是用词不当，会混淆可能查看我代码的其他程序员。我的“工厂”类不决定实例化哪个具体类，它们保证一系列对象将以正确的顺序实例化，并且当我调用 new() 时，正确的类将传递给正确的构造函数。

例如，对于我正在处理的一个 MVVM 项目，我编写了一个类来确保我的 SetupView 被正确实例化。它看起来像这样：

public class SetupViewFactory
{
    public SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities)
    {
        var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities);
        var setupView = new SetupView();
        setupView.DataContext = setupViewModel;
        return setupView;
    }
}

称其为“工厂”会不会令人困惑？它不会在几个可能的具体类中做出决定，它的返回类型不是接口或抽象类型，但它确实封装了对象实例化.

如果不是“工厂”，那是什么？

---

编辑

许多人认为这实际上是建造者模式。

来自dofactory的Builder Pattern的定义如下：

将复杂对象的构造与其表示分离，以便相同的构造过程可以创建不同的表示。

这似乎也有点牵强。困扰我的是“不同的表示”。我的目的不是抽象构建视图的过程（不是说这不是一个有价值的目标）。我只是试图将创建特定视图的逻辑放在一个地方，这样如果创建该视图的任何成分或过程发生变化，我只需更改这一类。构建器模式似乎真的是在说，“让我们为创建视图创建一个通用过程，然后您可以为创建的任何视图遵循相同的基本过程。”很好，但这不是我在这里做的。

---

编辑 2

我刚刚在Wikipedia article on Dependency Injection 中发现了一个有趣的例子。

在“手动注入的依赖”下，它包含以下类：

public class CarFactory {

    public static Car buildCar() {
        return new Car(new SimpleEngine());
    }

}

这几乎是完全我的用法（而且，不，我没有写维基文章:)）。

有趣的是，这是这段代码后面的注释：

在上面的代码中，工厂负责组装汽车，并将发动机注入汽车。这使汽车无需了解如何创建引擎，尽管现在 CarFactory 必须了解引擎的构造。可以创建一个 EngineFactory，但这只会在工厂之间创建依赖关系。所以问题仍然存在，但至少已经转移到 factories 或 builder 对象中。 [我的重点]

所以，这告诉我，至少我不是唯一一个想创建一个类来帮助将东西注入另一个类的人，也不是唯一一个试图将这个类命名为工厂的人。

Answer 1

在我看来，这与 SetupView 实例的构造函数没有太大区别。也许您的示例中省略了太多代码上下文，但我不明白为什么您在那里拥有的内容不能简单地写为构造函数，并将参数作为 args 传递给构造函数。

严格从 GoF 模式来看，我认为它与 Factory 不符有两个原因：

1. 没有相关/依赖对象系列
2. 确实指定了具体类

关于Builder，我认为它在产品的差异方面有所遗漏。

当我教授设计模式课程时，我告诉学生在尝试确定“最合适”时不仅要看模式的意图，还要看适用性和结构/参与者。意图可以帮助您排除问题，但适用性和结构/参与者将帮助您找到正确的方向。

如果您可以确定设计的哪一部分满足（抽象）工厂或构建器参与者的各种角色，那么您就为使用该命名法提供了一个很好的案例。

Answer 2

在我看来，您所拥有的更多的是 Builder 模式，而不是 Factory 模式。

Answer 3

我认为，它是一个“工厂”。当我查看类声明时，我很高兴看到这是一个“工厂”，而且它是一个 SetupView 对象的“工厂”。所以我知道这个 Factory 会为我提供具体且正确构建的 SetupView 实例。

Answer 4

GoF 称之为“Builder”

Answer 5

“工厂”是封装新对象实例化的任何东西。为什么，或者对象是什么，并不重要。最常见的用途是您所描述的，但其他不符合该描述的用途也可以称为工厂。基本的想法，（我认为除了最讨厌或最挑剔的开发人员之外，其他人都不会误解），就是这个东西为你实例化了新的对象......

Answer 6

这对我来说似乎有点奇怪。它不是一个抽象工厂，但也不完全符合 Builder 模式。对我来说最有意义的是不是让 SetupViewFactory 与 CreateView 方法一起使用，而是将此方法移动到 SetupView 类并使其成为静态。所以你会有...

public class SetupView
{
    public static SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities)
    {
        var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities);
        var setupView = new SetupView();
        setupView.DataContext = setupViewModel;
        return setupView;
    }
}

现在您有了所谓的静态工厂或工厂方法。您可以更进一步，将 SetupView 构造函数私有化，以便获取 SetupView 实例的唯一方法是调用工厂方法。

回应 OP 的评论：

如果需要分离，我会避免在这部分代码的任何位置创建 SetupViewModel。相反，只需传入要与 SetupView 关联的 SetupViewModel，而不是传递给 SetupViewModel 构造函数的组成属性。于是代码就变成了……

public class SetupView
{
    public static SetupView CreateView(SetupViewModel model)
    {
        var setupView = new SetupView(); { DataContext = model };
        return setupView;
    }
}

Answer 7

为什么不是两个具有简单构造函数的类？

 public class SetupViewModel {
      public SetupViewModel(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities) {
          this.DatabaseModel = databaseModel;
          this.SettingsModel = settingsModel;
          this.ViewUtilities = viewUtilities;
      }
 }

和

 public class SetupView {         
      public SetupView(SetupViewModel model) {              
          this.DataContext = model;
      }
 }

这样，两个类都清楚地说明了它们需要构造的内容。

Answer 8

你可以称它为“巫师”。

Answer 9

我倾向于同意上面的 Jason。对我来说，它更像是一个 Builder 模式，但如果你把 SetupView 变成一个界面，它更像是一个工厂模式。工厂模式的关键是让工厂模式完成所有工作来决定从函数调用中返回什么。因此，我认为您必须在给定输入参数的情况下在各种选项之间进行切换。