Does the Builder pattern really need a Director?
A Builder knowshow to construct the various parts of an aggregate, while a Director knows theorder in which they should be constructed. Wikipedia illustrates this pattern with a PizzaBuilder example:
http://en.wikipedia.org/wiki/Builder_pattern
I find it difficult to understand why one would not move the constructPizza() method (including its implementation) of Waiter (the Director) to PizzaBuilder (the abstract Builder), bypassing Waiter altogether:
PizzaBuilder hawaiianPizzaBuilder =new HawaiianPizzaBuilder();
hawaiianPizzaBuilder.constructPizza();
Pizza pizza = hawaiianPizzaBuilder.getPizza();
Why is it so important to separate thehow from theorder? To me it looks like having a separate Director class makes things just more complicated without having real benefits.
[887 byte] By [
CBya] at [2007-11-27 5:06:10]
# 1
> Why is it so important to separate the how
> from the order? To me it looks like having a
> separate Director class makes things just more
> complicated without having real benefits.
I think the pizza example is a poor one.The problem is that if you embed the order into the AbstractBuilder, you have only one order. Builders are good at doing things like building a GUI screen from an input file. If you separate the director from the builder, the builder could be used with any number of file formats. For example, you might have a director that parses an XML document and then calls the builder methods accordingly. You could have another director that does this from a database. The builder doesn't change. If you couple the builder to one order or one way of recieving commands, it's a lot less resuable.
# 2
> The problem is that if you embed the order into the
> AbstractBuilder, you have only one order.
Thank you for your reply. Are you suggesting that real-world applications have several Directors that differ in the order of construction? I just got myself the GoF book and it speaks about just one Director, which repeats the same construction process, independent of the concrete builder passed to it.
I was thinking of using this pattern to create a custom JTree in subsequent steps: 1) create the nodes from a database, 2) create the tree model, 3) create the tree. Right now everything happens in my JTree constructor, which doesn't feel right since it's just a GUI component. Would that be appropriate? I only have one concrete builder now, so it seems a bit too much.
CBya at 2007-7-12 10:24:49 >
# 3
Concrete builders objects contain the algorithms for building parts of something. For example, if you were building legal contracts, your building object would contain methods for putting together clauses, sections, etc. The building object itself would not know how to build a complete legal contract. It only contains the code for building the parts of contracts.
Here comes the Director. A Director knows what needs to be built and how to do it. A Director is a smart guy. The code in a Director, written by you the Programmer, knows how to control/command the builder objects in order to build a legal contract.
You can have many different types of legal contracts. A RealEstateDirector might know how to build selling agreements. A EntertainmentDirector might know how to build entertainment contracts.
The documentation that is in the GoF book is a guide only for the design pattern. How a design pattern is implemented is different. An implementation of a design pattern should be governed by the business/domain requirements.
If an application needs multiple director and builder objects, then that is what it needs.
The pattern is most useful when an object needs to build different, related, classes using a consistent procedure. A Director has the general algorithm for executing the building process, while the Builder(s) actually carry out each phase on the specific thing it is able to build.
Consider my example. Here we are using the Builder design pattern to build a legal contract using a consistent procedure which can be easily adapted and configured.
You are thinking of using the Builder design pattern to build a JTree. Do you really need the Builder pattern to build a JTree?
/>
# 4
> Thank you for your reply. Are you suggesting that
> real-world applications have several Directors that
> differ in the order of construction? I just got
> myself the GoF book and it speaks about just one
> Director, which repeats the same construction
> process, independent of the concrete builder passed
> to it.
If you look at the Consequences, list item 2 it states:
"..then different Directors can reuse it to build Product variants from the same set of parts. In the earlier RTF example, we could define a reader for a format other than RTF, say, an SGMLReader, and use the same TextConverters..."
Note that in the example the Reader is the Director and the TextConverter is the Builder.
The point of this pattern is to separate the code that knows what to do and the code that knows how to do it so that they can be combined indpendently.
Suppose you were writing a tool that could take XML or database rows and create a Swing GUI. Let's say you are also asked to take that XML and those database rows and create a web page.
If you combine the code that reads the input with the code that reads the output, you end up writing the xml reader twice, the database reader twice, the swing builder twice, and the web page builder twice. Then consider what happens if you need a third input format or more output formats.
> I was thinking of using this pattern to create a
> custom JTree in subsequent steps: 1) create the nodes
> from a database, 2) create the tree model, 3) create
> the tree. Right now everything happens in my JTree
> constructor, which doesn't feel right since it's just
> a GUI component. Would that be appropriate? I only
> have one concrete builder now, so it seems a bit too
> much.
I would remove any knowledge of the database from your gui component. This doesn't require more code and it won't make things more complicated. I think you'll find that once you have done it, it will make things a lot easier to understand and work on. The idea that every Object should have a single responsibility is poorly defined but is, in my opinion, a very good way to think about your designs.
# 5
> I was thinking of using this pattern to create a
> custom JTree in subsequent steps: 1) create the nodes
> from a database, 2) create the tree model, 3) create
> the tree. Right now everything happens in my JTree
> constructor, which doesn't feel right since it's just
> a GUI component. Would that be appropriate? I only
> have one concrete builder now, so it seems a bit too
> much.
One thing to note is that the JTree is in effect a very generic concrete builder. If that's all you need right now, you don't need to write your own builder, just a class that converts the input into the JTree calls. If you later need to have other inputs, you can refactor out a custom builder pattern while reusing the code for the Tree in one concrete implementation.
# 6
/**
* This class is used to make many different types of Pizza's. It needs instructions.
*/
public class PizzaBuilder {
public void chopOnions() { ... }
public void chopTomatoes() { ... }
public void chopMushrooms() { ... }
public void makeMeatballs() { .... }
public void sliceSausages() { .... }
public void makeSourDough() { ... }
public void makeSpicyDough() { ....}
public void grateCheese(String type) { ... }
public void addCheese() { ... }
public void addSalt(String amount) { ...}
public void addOliveOil() { ...}
...
}
/**
* This class is used to make Pizzas. It contains the methods and algorithms for making all different types of yummy Pizzas.
*/
public class PizzaDirector() {
private PizzaBuilder builder;
public PizzaDirector() { this.builder = new PizzaBuilder();}
public Pizza makeNepolitanPizza(String size, String toppings) { ...}
public Pizza makeSicilianPizza(String size, String toppings) { ...}
public Pizza makeNewYorkStylePizza(String size, String toppings) { ...}
}
If an algorithm was hard-coded in the PizzaBuilder class for making a specific type of pizza in a certain way, then if you needed to make a Pizza in a different way, you would need to write another builder class and would most likely have to copy code (increase redundancy).
Coding in this fashion is bad news for significant enterprise systems and increases room for more errors and bugs and inconsistency.
A Director then is required to help maintain a fine separation between what to build and how to build it.
# 7
Thank you both for your time. It's most helpful to me.
> If you look at the Consequences, list item 2 it states: ...
You are right. I misread that section and interpreted the plural as instances of the same class, which differ only in the concrete builder passed. They are actually talking about different Director classes here. Thanks for pointing that out. I think I begin to understand why a separate Director class is useful.
In GoF, the Director is actually doing something: reading RTF. That's logic that deserves its own class. In the PizzaBuilder example, the role of the Director is less obvious to me: it seems a superfluous intermediate that is just passing messages. Maybe that's the source of my misunderstanding.
Constructing a tree consists of some clearly defined individual steps: buildTreeNodes, buildTreeModel, buildTree. I need some class to assemble it, because it doesn't feel right to perform all these steps in my custom JTree constructor or main frame. That's why I was thinking of this pattern, but maybe you are right and is a simple helper class sufficient in my case.
CBya at 2007-7-12 10:24:49 >
# 8
Not sure if this is appropriate, but here's an interesting discussion on the differences/uses for Builder and Abstract Factory (especially how the director/architect plays a role). http://forums.ultrashock.com/forums/showthread.php?s=&threadid=76733
# 9
> In GoF, the Director is actually doing something:
> reading RTF. That's logic that deserves its own
> class. In the PizzaBuilder example, the role of the
> Director is less obvious to me: it seems a
> superfluous intermediate that is just passing
> messages. Maybe that's the source of my
> misunderstanding.
Right. The PizzaBuilder example is a poor one because it uses a static builder. A lot of examples in OO suffer from this issue. The author uses an example that is simple to understand but often leaves it up to the reader to make the connection to real coding problems. The first part is good but the second part is unrealistic.
