Differences between builder pattern and template method (builder vs template)

Question

Template pattern provides algorithm in the base class whose steps can be modified in the derived class. In Builder pattern, concrete builder exposes methods for building a product which are called from the Director class.

I understand there is difference with respect to the purpose of using these patterns. Template pattern is a behavioral pattern which changes one or more steps in a template whereas builder pattern is a Creational pattern.

Apart from the above said difference, are there any other differences?

Isn't director in builder pattern acting as a base template in template pattern. The concrete builders are acting like derived classes in the template pattern with substitutable steps?

Can someone please clarify. Thank you.

I am referring http://www.dofactory.com/Patterns/Patterns.aspx

Answer 1

The builder pattern

The builder pattern is used to construct a more complex object.

Let's say that we want to construct different Saab (car brand) models. Each model has different engines, lights, etc.

If we were to use the template method pattern, we had to create one class for every single combination of cars or use some nasty inheritance hierarchies. A lot of those methods would also contain duplicate code.

With the build pattern, we can instead take different parts and compose those together to create a complete car. Hence we can reuse an engine for every model if needed, and we can also customize each part of the car.

Template method

The template method, on the other hand, is used to abstract away some creations to avoid coupling implementations in your code against a specific framework/library (usually).

For instance. You might have an IWebRequest interface, which can be implemented using WebSocketRequest or HttpRequest. Those implementations, in turn, are tightly coupled with the corresponding Response classes. If you want to support them, you have to have if statements in every place that you want to create them.

if (request is WebSocketRequest)
  response = new WebSocketResponse();
else
  response = new HttpResponse();

With the template method, on the other hand, you can create the method IWebReponse in the IHttpRequest interface. In that way, all code that uses the requests is implementation agnostic.

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

Before I start, my universal line for all my answers: "Any programming concept in any language requires to understand in three ways. (a)From design perspective(b)Runtime perspective(c)From Memory perspective.

Having said that ppl giving ans based on (a) may not agree with (b)'s and vice versa (or may be some one will give circular explanation to pollute clear definition). Pizza builder, Restaurant builder, Car builder or UI template, workflow template does not make any sense when in an enterprise project you are ask to implement Builder/Template Pattern(may be these patterns are not much mature to define themselves). The reason for failure is if I know some object has to be build in 4 steps then why I will start instantiating it from empty and fill it in steps one by one step using director. What will happen if I don't want step 3 or too many exceptions are happening on step 2. Instead I will create final object when all 4 steps are done(this is exactly happened with me thru out my career and tht's why builder pattern is not adopted by developers). Here ppl may argue in distributed systems where asyn behaviour is required then Builder can help; but if that is the case then I would still be relying on onreadystatechange==4 and then instantiate my builderObj. So we should not use Builder ? IMHO answer is "NO".

My understanding is in .net we have ControllerBuilder, SqlConnectionStringBuilder, UriBuilder; all are customizing ControllerFactory, Sql, Uri Factories; then my main program can use those factories to generate Controllers, ConnStrings, Uries. So Builder pattern is for factory setup customization ? do we need factory setup customization ? Probably never; instead the best I will do is creating 4 async methods and chain them with step 2 parameters(on second chaining step 3 parameters ...). What abt template pattern (asp.net workflow template or jQuery template or canned template). For me both are same but compare to builder, template is more rigid in nature(almost everything fixed, very few properties wud be changing to define a specific tmplt) and once template is defined then factory. Another rumor also I have seen for these two is capable of "Any Factory->Any Product" as When would you use the Builder Pattern? ; but that is not true bcoz its similar to above .net ControllerBuilder, sql, uri scenario with "Factory of Factory" concept. Which is against many design principals (SRP, LSP, bad encapsulation). Hope my full writing about these two would help from beginner to advanced.