dev*_*xer 5 c# design-patterns factory naming-conventions
我对工厂的理解是它封装了所有继承公共抽象类或接口的具体类的实例化.这允许客户端与确定要创建哪个具体类的过程分离,这反过来意味着您可以从程序中添加或删除具体类,而无需更改客户端的代码.你可能不得不改变工厂,但工厂是"专门建造的",实际上只有一个改变的理由 - 添加/删除了一个具体的类.
我已经构建了一些实际上封装了对象实例化的类,但原因不同:对象很难实例化.目前,我将这些类称为"工厂",但我担心这可能是一种误称,并会混淆其他可能会查看我的代码的程序员.我的"工厂"类没有决定实例化哪个具体类,它们保证一系列对象将以正确的顺序实例化,并且当我调用时,正确的类将被传递给正确的构造函数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;
}
}
把它称为"工厂"是否令人困惑？它不决定几个可能的具体类,它的返回类型不是接口或抽象类型,但它确实封装了对象实例化.
如果它不是"工厂",它是什么？
编辑
很多人都认为这实际上是Builder Pattern.
从dofactory定义Builder Pattern 如下:
将复杂对象的构造与其表示分开,以便相同的构造过程可以创建不同的表示.
这似乎也有点延伸.困扰我的是"不同的表现形式".我的目的不是抽象构建视图的过程(不是那个不值得的目标).我只是想在一个地方设置创建特定视图的逻辑,这样如果任何成分或创建该视图的过程发生变化,我只需要更改这一个类.构建器模式似乎真的在说,"让我们创建一个创建视图的一般过程,然后您可以为您创建的任何视图执行相同的基本过程." 很好,但那不是我在这里做的.
编辑2
我刚刚在维基百科关于依赖注入的文章中找到了一个有趣的例子.
在"Manually Injected依赖"下,它包含以下类:
public class CarFactory {
public static Car buildCar() {
return new Car(new SimpleEngine());
}
}
这几乎是完全相同的使用我有(和,不,我没有写wiki文章:)).
有趣的是,这是此代码后面的注释:
在上面的代码中,工厂负责组装汽车,并将发动机注入汽车.这让汽车免于了解如何制造发动机,尽管现在CarFactory必须知道发动机的结构.可以创建一个EngineFactory,但这只会创建工厂之间的依赖关系.所以问题仍然存在,但至少已转移到工厂或构建器对象中.[我的重点]
所以,这告诉我,至少我不是唯一一个想要创建一个类来帮助将东西注入另一个类的人,而我并不是唯一一个试图将这个类命名为工厂的人.
对我来说，这与 SetupView 实例的构造函数没有太大不同。也许您的示例中省略了太多的代码上下文，但我不明白为什么您所拥有的内容不能简单地编写为构造函数，并将参数作为参数传递给构造函数。
严格从 GoF 模式来看，我认为它没有达到 Factory 的标准，原因有两个：
关于Builder，我认为它在产品差异性方面有所欠缺。
当我教授设计模式课程时，我告诉学生在尝试确定“最适合”时不仅要考虑模式的意图，还要考虑适用性和结构/参与者。意图可以帮助你排除问题，但适用性和结构/参与者可以帮助你熟悉。
如果您可以确定设计的哪一部分满足（抽象）工厂或构建器中参与者的各种角色，那么您就已经为使用该术语做好了充分的准备。