design-patterns - 构建器模式和模板方法之间的差异（构建器与模板）

Question

模板模式在基类中提供算法，其步骤可以在派生类中修改。在构建器模式中，具体构建器公开了用于构建产品的方法，这些方法从 Director 类中调用。

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

除了上面所说的不同，还有其他的不同吗？

构建器模式中的主管不是作为模板模式中的基本模板。具体的构建器就像模板模式中的派生类一样，具有可替换的步骤？

有人可以澄清一下。谢谢你。

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

Answer 1

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

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

假设我们要构建不同的 Saab（汽车品牌）模型。每个型号都有不同的引擎，灯等。

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

使用构建模式，我们可以取而代之的是，将不同的部分组合在一起，形成一辆完整的汽车。因此，如果需要，我们可以为每个模型重用一个引擎，我们还可以定制汽车的每个部分。

Answer 2

I found the same question very interesting.

The Saab car example is interesting but it does not adhere to the description of Builder pattern in "Gang of Four" (Design Patterns).

I will be using "Gang of Four" terminology.

In Gang of Four, there cannot be a blend of concrete builders per each invocation of aDirector->Construct() so the Saab example, while is interesting does not answer the question really for me.

I see some:

The separation of the director object from the builder hierarchy is a key difference. In the Template Factory both the method that embodies the generalized flow and the overriden methods are members of the same class. This makes the Builder pattern better at encapsulating the internal stages of the process since client code is less likely to come in contact with such methods if accessing only the Director object. Builder pattern also allows for a formulation of the assembly process completely independently from the Builder hierarchy, allowing for a more flexible replacement of the builder instance when needed. For example, once you have a director instance at hand you can easily build several representations of the product, each time dynamically replacing the concrete builder. So the builder is more dynamic and better encapsulates the inner workings of the concrete builder.

In addition, if you want to elaborate on the Director object by inheritance you may do so without multiplying your hierarchy. For example, you may have an express process of building for saving time before the final construction - you can subclass the Director object or even use "Template Method" on it in itself to customize it by inheritance without requiring to reimplement your concrete builders.

But this leads us to consider another pattern which is closely related to "Template Factory" - the "Strategy" pattern.

Strategy is very much like Template Factory, with two clear differences: it too separates a Context object from the Strategy hierarchy allowing for switching algorithms for a single problem instance in runtime. Another difference is that the examples seem to suggest that invoking the Strategy does not necessarily involve a complex or structured process as in "Template Method".

But I bring it here for as an analogue to Builder to get to another point - If "Strategy" is parallel in its class structure to Builder, then the parallel creational pattern to "Template Method" should be "Factory Method". This is clear, not only by name, but interestingly enough, the discussions both chapters of the book for "Factory method" and "Template method" use almost identical examples (an application for editing documents).

So, without going into the question of what is the difference between creational and behavioral patterns, I tend to think that both Builder and Factory Method are basically specific cases and refinements of Strategy and Template Method, respectively.

So the question becomes - if you see no difference between Builder and Template Factory - try to answer these questions:

1. What perspective do you prefer having on that particular part of the system? Is it "behavior" or "creation"? and

2. Do you require strong encapsulation, or the dynamic replacement or deployment or tweaking of a builder instance, on one hand, or do you expect complexity (by inheritance, composition, or otherwise) to evolve around the creation process or template method? If the answer to any of these questions go with the Builder/Strategy structure. Otherwise, the use simple polymorphysm of relation or behavior in the XX Method patterns.

Answer 3

在我开始之前，我所有答案的通用路线：“任何语言的任何编程概念都需要从三种方式理解。（a）从设计角度（b）运行时角度（c）从内存角度。

话虽如此，基于（a）给出答案的人可能与（b）不一致，反之亦然（或者可能有人会给出循环解释以污染明确的定义）。Pizza builder、Restaurant builder、Car builder 或 UI 模板、工作流模板在企业项目中被要求实施 Builder/Template Pattern 时没有任何意义（可能是这些模式对自己的定义不够成熟）。失败的原因是如果我知道某些对象必须分 4 步构建，那么为什么我会从空开始实例化它并使用 director 一步一步地填充它。如果我不希望第 3 步或第 2 步发生太多异常会发生什么。相反，我将在完成所有 4 个步骤后创建最终对象（这在我的整个职业生涯中完全发生在我身上）s 为什么开发人员不采用构建器模式）。在这里，人们可能会在需要异步行为的分布式系统中争论，然后 Builder 可以提供帮助；但如果是这种情况，那么我仍然会依赖 onreadystatechange==4 然后实例化我的builderObj。所以我们不应该使用 Builder 吗？恕我直言，答案是“不”。

我的理解是在 .net 中我们有 ControllerBuilder、SqlConnectionStringBuilder、UriBuilder；都在定制ControllerFactory、Sql、Uri Factory；然后我的主程序可以使用这些工厂来生成 Controllers、ConnStrings、Uries。那么 Builder 模式是用于工厂设置定制的吗？我们需要工厂设置定制吗？可能永远不会；相反，我会做的最好的事情是创建 4 个异步方法并使用步骤 2 参数链接它们（在第二个链接步骤 3 参数中......）。什么 abt 模板模式（asp.net 工作流模板或 jQuery 模板或罐装模板）。对我来说，两者都是相同的，但与 builder 相比，模板本质上更加严格（几乎所有东西都是固定的，很少有属性需要更改以定义特定的 tmplt），一旦定义了模板，然后是工厂。你什么时候会使用建造者模式？; 但这不是真的，因为它类似于上面带有“工厂工厂”概念的 .net ControllerBuilder、sql、uri 场景。这违反了许多设计原则（SRP、LSP、不良封装）。希望我关于这两个的完整文章能帮助从初学者到高级。

Answer 4

我已经阅读了一篇很好的文章，其中指定了这两者之间的用途和差异。

关联