是否有一种模式，您有一个类，其作用是实例化另一个类的常见实现？

Question

我想把它称为“助手”，但这似乎太笼统了。

假设我有一个名为WidgetCranker的类，WidgetCranker可以设置为生成Square，Keyhole和GearShape类型的小部件。我还可以指定哪些Color我想要我的小部件以及哪些Label我想要盖章。

现在，设置WidgetCranker的每个单独实例都非常复杂，构造函数只是为您提供一个空WidgetCranker，您必须手动设置要创建的小部件的类型和颜色。< / p>

WidgetCranker keyholeWidget = new WidgetCranker();
keyholeWidget.Type = WidgetTypes.Keyhole;
keyholeWidget.Color = WidgetColors.Red;
keyholeWidget.Label = "ACME Industries Prototype 1";

但是我有一个类需要很多WidgetCranker，除了标签之外几乎看起来都一样。我想让我的代码更易读，更难以维护，所以我创建了一个帮助类，为我完成了所有的工作。所以上面现在变成了：

WidgetCranker keyholeWidget = WidgetCrankerHelper.RedKeyhole("ACME Industries Prototype 1");

我的问题有两个：

1. 这是一个实际的设计模式，如果是这样，我们称之为什么？我想把它称为工厂，但绝对不是工厂模式。我们在每种情况下都创建完全相同类型的对象，只是以不同方式实例化它们。我知道这是一种“助手”，但如果可以的话，我想要比这更具体。这是一个非常具体的帮手。

2. 鉴于“Helper”是一个非常通用的名称，我觉得仅仅根据它产生的方法来命名方法是不够的。我应该这样命名，以便它显而易见。那么MakeRedKeyhole会更好还是BuildRedKeyhole？我不想使用GetRedKeyhole，因为这意味着我们将返回对现有实例的引用，而不是创建一个全新的实例。

Answer 1

我倾向于远离“助手”一词，因为所有课程都应该有用，对吗？ ：）

我认为将其称为Factory或Builder是可以接受的。抽象工厂的要点是封装对象的构造/实例化。 可以返回不同的类型，但它不需要 。消耗工厂的类型不应该在乎。

在进行任何类似的复杂构造时，我倾向于使用“Builder”名称。