1

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

假设我有一个名为的类，WidgetCranker并且WidgetCranker可以设置为生成 和 类型的小部件。我还可以指定我想要我的小部件是什么以及我想要在它们上面加盖什么。SquareKeyholeGearShapeColorLabel

现在，设置每个单独的实例WidgetCranker是相当复杂的，构造函数只是给你一个空的WidgetCranker，你必须手动设置你想要启动的小部件的类型和颜色。

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

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

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

我的问题是双重的：

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

  2. 鉴于“Helper”是一个非常通用的名称，我觉得仅仅通过它产生的方法来命名是不够的。我应该给它命名，这样它的作用就很明显了。那么会MakeRedKeyhole更好还是BuildRedKeyhole？我不想使用GetRedKeyhole，因为这意味着我们正在取回对现有实例的引用，而不是创建一个全新的实例。

4

1 回答 1

0

我倾向于远离“帮助者”这个词，因为所有课程都应该有帮助，对吧？:)

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

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

于 2013-11-30T02:16:00.570 回答