构建器模式和模板方法之间的差异(构建器与模板)

时间:2011-04-15 09:00:09

标签: design-patterns builder template-method-pattern

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

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

除上述差异外,还有其他差异吗?

构建器模式中的director不是模板模式中的基本模板。具体的构建器在模板模式中的作用类似于具有可替换步骤的派生类吗?

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

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

3 个答案:

答案 0 :(得分:8)

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

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

让我们说我们想要构建不同的萨博(汽车品牌)模型。每个型号都有不同的发动机,灯等。

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

使用构建模式我们可以改为使用不同的部件并将它们组合成一辆完整的汽车。因此,如果需要,我们可以为每个模型重复使用引擎,我们也可以自定义汽车的每个部分。

答案 1 :(得分:6)

我发现同样的问题非常有趣。

Saab汽车的例子很有意思,但它不符合“四人帮”(设计模式)中的Builder模式的描述。

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

在Gang of Four中,每次aDirector->Construct()的调用都不可能混合使用混凝土构造器,所以萨博的例子虽然很有趣但并没有真正回答我的问题。

我看到了一些:

导向器对象与构建器层次结构的分离是一个关键区别。在模板工厂中,体现广义流的方法和重写方法都是同一个类的成员。这使得Builder模式更好地封装了流程的内部阶段,因为如果仅访问Director对象,则客户端代码不太可能与这些方法接触。 Builder模式还允许完全独立于Builder层次结构的装配过程的公式,允许在需要时更灵活地替换构建器实例。例如,一旦掌握了导演实例,您就可以轻松地构建产品的多个表示,每次动态替换混凝土构建器。因此,构建器更具动态性,更好地封装了混凝土构建器的内部工作方式。

此外,如果要通过继承详细说明Director对象,则可以在不增加层次结构的情况下执行此操作。例如,您可能有一个明确的构建过程,以便在最终构造之前节省时间 - 您可以继承Director对象,甚至可以在其上使用“Template Method”来通过继承对其进行自定义,而无需重新实现您的具体构建器。 / p>

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

策略与模板工厂非常相似,有两个明显的区别:它将Context对象与Strategy层次结构分开,允许在运行时为单个问题实例切换算法。另一个不同之处是,这些示例似乎表明,调用策略并不一定涉及“模板方法”中的复杂或结构化过程。

但是我把它带到这里作为Builder的类比来达到另一个点 - 如果“Strategy”在它的类结构中与Builder并行,那么“Template Method”的并行创建模式应该是“Factory Method”。这很清楚,不仅仅是名字,但有趣的是,讨论“工厂方法”和“模板方法”这两本书的章节使用了几乎相同的例子(编辑文件的应用程序)。

因此,在没有涉及创造和行为模式之间的区别的问题的情况下,我倾向于认为Builder和Factory Method分别是策略和模板方法的特定案例和改进。

所以问题就变成了 - 如果你发现Builder和Template Factory之间没有区别 - 试着回答这些问题:

  1. 您更喜欢对系统的某个特定部分有什么看法?是“行为”还是“创造”?以及

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

答案 2 :(得分:0)

在我开始之前,我的所有答案的通用线:“任何语言的任何编程概念都需要以三种方式理解。(a)从设计角度来看(b)运行时角度(c)从内存角度来看。

已经说过,根据(a)给出ans的人可能不同意(b),反之亦然(或者可能是某人将给出循环解释以污染明确的定义)。在企业项目中,当您要求实施构建器/模板模式时,披萨构建器,餐厅构建器,汽车构建器或UI模板,工作流模板没有任何意义(可能这些模式不是很成熟,无法定义自己)。失败的原因是如果我知道某个对象必须以4个步骤构建,那么为什么我将从空开始实例化它并使用director逐步填充它。如果我不想要步骤3或者在步骤2中发生太多异常会发生什么。相反,当完成所有4个步骤时,我将创建最终对象(这恰好发生在我的职业生涯中,这就是为什么构建器模式是没有被开发者采用)。在这里,ppl可能会在需要asyn行为的分布式系统中争论,然后Builder可以提供帮助;但如果是这种情况,那么我仍然依赖于onreadystatechange == 4然后实例化我的builderObj。所以我们不应该使用Builder?恕我直言的答案是“不”。

我的理解是在.net中我们有ControllerBuilder,SqlConnectionStringBuilder,UriBuilder;所有都是自定义ControllerFactory,Sql,Uri工厂;然后我的主程序可以使用这些工厂生成控制器,ConnStrings,Uries。那么Builder模式是用于工厂设置定制的?我们需要工厂设置定制吗?可能永远不会;相反,我要做的最好的是创建4个异步方法并用步骤2参数链接它们(在第二个链接步骤3参数...)。什么是abt模板模式(asp.net工作流模板或jQuery模板或罐头模板)。对我来说两者都是相同的,但与构建器相比,模板本质上更加严格(几乎所有东西都已修复,很少有属性可以改变以定义特定的tmplt),一旦模板被定义为工厂。我已经看到的另外两个谣言是“任何工厂 - >任何产品”能够When would you use the Builder Pattern?;但这不是真正的bcoz它与上面相似  .net ControllerBuilder,sql,uri场景与“Factory of Factory”概念。这是针对许多设计原则(SRP,LSP,错误的封装)。希望我对这两篇文章的全面写作有助于从初学者到高级。