代码之家 › 专栏 › 技术社区 › devuxer

把这类称为“工厂”会让人困惑吗?

factory design-patterns naming-conventions c#

devuxer · 技术社区 · 16 年前

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

我构建了一些类,它们实际上封装了对象实例化,但原因不同:对象很难实例化。目前,我将这些类称为“工厂”,但我担心这可能是一个用词不当的问题,并会使其他可能查看我的代码的程序员感到困惑。我的“工厂”类不决定实例化哪个具体类,它们保证以正确的顺序实例化一系列对象,并且在调用时将正确的类传递给正确的构造函数 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 详情如下:

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

Wikipedia article on Dependency Injection

在“手动注入依赖项”下,它包含以下类:

public class CarFactory {

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

}

确切地 我的用法(不,我没有写wiki文章:)。

有趣的是,以下是代码后面的注释:

工厂或 建设者 物体。[我的重点]

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

9 回复 | 直到 16 年前

Chris Cleeland 16 年前

对我来说,这与SetupView实例的构造函数没有太大区别。也许您的示例中省略了太多的代码上下文,但我不明白为什么您的代码不能简单地编写为构造函数,并且参数作为参数传递给构造函数。

没有相关/从属对象的族
确实,具体类别是特定的

如果您能够确定设计的哪一部分满足(抽象)工厂或建筑商中参与者的各种角色,那么您就有了一个使用该术语的好案例。

Robert Harvey 16 年前

在我看来,你所拥有的更多的是 Builder 模式比图案

Erkan Haspulat 16 年前

Victor Sergienko 16 年前

GoF称之为“ Builder "

Charles Bretana 16 年前

“工厂”是封装新对象实例化的任何东西。为什么,或者物体是什么,都无关紧要。最常见的用途如您所述,但不符合该描述的其他用途也可以称为工厂。最基本的想法(我不认为除了最爱分析或挑剔的开发人员之外,任何人都会误解)是,这个东西为您实例化了新对象。。。

Indeed is Trash 16 年前

我觉得这有点奇怪。它不是一个抽象的工厂,但它也不太适合构建器模式。对我来说最有意义的是,我将把这个方法移到SetupView类中,并使其成为静态的,而不是将SetupViewFactory与CreateView方法一起使用。所以你会。。。

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;
    }
}

针对OP的评论:

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

Jeff Sternal 16 年前

为什么不使用两个具有简单构造函数的类呢?

 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;
      }
 }

这样,两个类都清楚地说明了它们需要构造什么。

T.E.D. 16 年前

你可以称之为“向导”。

Excalibur2000 16 年前

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