构建器模式和模板方法之间的差异（构建器vs模板）

Question

模板模式在基类中提供算法，其中的步骤可以在派生类中修改。 在Builder模式中，混凝土生成器公开了构建由Director类调用的产品的方法。

我知道使用这些模式的目的有所不同。模板模式是改变模板中的一个或多个步骤的行为模式，而构建器模式是创建模式。

除了上述差异，还有其他的区别吗？

作为模板模式中的基础模板充当构建器模式中的导演。具体的构建者像模板模式中的派生类一样具有可替代的步骤？

有人可以请澄清。谢谢。

我指http://www.dofactory.com/Patterns/Patterns.aspx

Answer 1

模板方法实际上只是一个方式来定义每个子类必须定义一些方法。

构建器模式用于构造更复杂的对象。

可以说我们想要构建不同的萨博（汽车品牌）模型。每个模型有不同的引擎，灯光等

如果我们要使用模板方法模式，我们必须为汽车的每个单一组合创建一个类或使用一些讨厌的继承层次结构。很多这些方法也会包含重复的代码。

随着构建模式，我们可以采取不同的部分，并将它们组合成一辆完整的汽车。因此，如果需要，我们可以为每个模型重新使用一个引擎，并且我们还可以定制汽车的每个部分。

Answer 2

我发现同样的问题很有趣。

萨博汽车的例子很有趣，但它并没有遵循“四人帮”（Design Patterns）中Builder模式的描述。

我将使用“四人帮”术语。

在四人帮中，每次调用aDirector->Construct()时都不能混合混凝土建造者，所以萨博的例子虽然很有趣，但并不能真正为我回答这个问题。

我看到一些：

从建设者层次导演对象的分离是一个关键的区别。在模板工厂中，体现广义流的方法和重写方法都是同一类的成员。这使得Builder模式更好地封装了流程的内部阶段，因为如果仅访问Director对象，客户端代码不太可能与此类方法联系。构建器模式还允许完全独立于构建器层次结构来制定组装过程，从而允许在需要时更灵活地替换构建器实例。例如，一旦掌握了导演实例，您就可以轻松构建产品的多个表示形式，每次都可以动态替换具体的制造商。所以建筑师更具活力，更好地包装了混凝土建筑商的内部运作。另外，如果你想通过继承来详细说明Director对象，你可以这样做，而不需要乘以你的层次结构。例如，为了在最终构建之前节省时间，您可能需要一个快速构建过程 - 您可以继承Director对象的子类，或者在其上自己使用“Template Method”来通过继承来定制它，而无需重新实现具体的构建器。

但是这导致我们考虑另一种与“模板工厂” - “策略”模式密切相关的模式。

策略与Template Factory非常相似，它有两个明显的区别：它将Context对象与策略层次结构分开，允许在运行时切换单个问题实例的算法。另一个区别是，这些例子似乎表明，调用策略并不一定涉及如“模板方法”中那样复杂或结构化的过程。

但我在此将其作为Builder的模拟器，以便达到另一点 - 如果“策略”与Builder的类结构平行，则“模板方法”的平行创建模式应为“工厂方法” 。这一点很清楚，不仅仅是名称，而且有趣的是，本书的“工厂方法”和“模板方法”两章的讨论几乎都使用相同的示例（编辑文档的应用程序）。

因此，我没有想到创建和行为模式之间有什么区别，我倾向于认为生成器和工厂方法分别基本上是特定案例和策略和模板方法的改进。

所以，问题就变成 - 如果你看到Builder和模板厂之间没有区别 - 尝试回答这些问题：

1. 什么角度看，你更喜欢有对系统的特定部分？它是“行为”还是“创造”？和

2. 您是否需要强大的封装，或一方面动态替换或部署或调整构建器实例，或者您希望复杂性（通过继承，组合或其他方式）围绕创建过程发展或模板方法？如果任何这些问题的答案都与Builder/Strategy结构一致。否则，在XX方法模式中使用关系或行为的简单多态性。

Answer 3

我开始之前，我对我所有的答案通用线路：“在任何语言的任何编程的概念需要在三个方面来理解（一）从设计的角度来看（二）运行时的角度（三）从内存的角度。

说了，根据（a）给出答案的ppl可能不同意（b）的答案，反之亦然（或者可能有人会给出循环解释来污染明确的定义）比萨建造者，餐馆建造者，汽车制造商或用户界面模板，工作流程模板在企业项目中被要求实施Builder/Template Pattern时可能没有任何意义（可能这些模式不太成熟，无法定义自己）。失败的原因是，如果我知道一些目的必须以4个步骤来构建，那么为什么我会从空实例化它并使用导演一步一步地填充它。如果我不想要第3步或者第2步发生太多异常，会发生什么情况。相反，当完成所有4个步骤后，我会创建最终对象（这完全是在我的职业生涯中发生的，这就是为什么生成器模式是不被开发者采用）。在这里，ppl可能会在需要异步行为的分布式系统中争论，然后Builder可以提供帮助;但如果是这样的话，我仍然依靠onreadystatechange == 4然后实例化我的builderObj。所以我们不应该使用Builder？恕我直言回答是“否”。

我的理解是在.NET中，我们有ControllerBuilder类，SqlConnectionStringBuilder，UriBuilder;所有都在定制ControllerFactory，Sql，Uri Factory;那么我的主程序可以使用这些工厂来生成控制器，ConnStrings，Uries。所以构建器模式是用于工厂设置定制？我们是否需要工厂设置定制？可能永远不会;代替我将尽力创造4种异步方法和连锁它们与步骤2的参数（第二上链接步骤3参数...）。什么abt模板模式（asp.net工作流模板或jQuery模板或罐头模板）。对我而言，两者都是相同的，但与建设者相比，模板在本质上更加僵化（几乎所有的东西都是固定的，很少有属性会改变来定义特定的tmplt），一旦模板被定义，然后工厂。另有传闻我也已经看到了这两个能够“任何工厂 - >所有产品”为When would you use the Builder Pattern?的;但事实并非bcoz其类似于上面 .NET ControllerBuilder类，SQL，以“工厂的工厂”的概念URI方案如此。这违背了许多设计原则（SRP，LSP，不良封装）。希望我对这两篇文章的全面写作能够帮助从初级到高级。