Design Pattern: Builder

Question

I have looked for a good example of a Builder pattern (in C#), but cannot find one either because I don't understand the Builder pattern or I am trying to do something that was never intended. For example, if I have an abstract automobile and abstract builder methods to create car parts, I should be able to send all 30 of my choices to the Director, have it build the pieces I need, then build my automobile. Regardless of which car, truck, semi, etc. produced, I should be able to "drive" it in exactly the same way.

First problem is most examples hard code property values in to the concrete parts, which I really think should come from a database. I thought the idea was to send my choices to the Director (from a data source) and have the builder create a customized product based on my data.

Second problem is I want the builder methods to actually create the parts then assign them to the product, not pass strings but real strongly typed product parts.

For example, I want to create a form on the fly by having a Builder manufacture form fields for me, including a label, an input section, validation, etc. This way I can read the object from my ORM, check out the object's metadata, pass this to my Builder and add the newly created user control result to my web form.

However, every Builder example I find only has hard coded data instead of passing choices from the main code to the Builder and kicking out a customized product. Everything seems to be a big static case statement. For example, if I have three parameters with 10 choices each, I don't want to build 30 concrete Builder methods, I want to create only enough to manufacture the properties my product requires, which may be only three.

I am tempted to have the Director exist in the main code only. There should be a way to automatically determine which concrete builder method to call similar to polymorphism and method overloads (although that is a very bad example) instead of using a case statement within the pattern. (Every time I need to add a new product type, I will need to modify the existing Director, which is bad).

Answer 1

I am going refer to the C# example in the Wikipedia Article here.

First problem is most examples hard code property values in to the concrete parts, which I really think should come from a database. I thought the idea was to send my choices to the Director (from a data source) and have the builder create a customized product based on my data.

In this case you would have class implementing PizzaBuilder that knows how to retrieve data from a database. You can do it several ways.

One would be make a HawaiianPizzaBuilder. When the class initializes it queries the database for a Hawaiian Pizza and retrieves the row. Then when the various Build(x) methods are called it would set the properties to the corresponding field of the retrieved database row.

Another would be just makes a PizzaDatabaseBuilder and make sure that when you initialize the class you pass it the ID of the row you need for that type of pizza. For example instead of

waiter.PizzaBuilder = new HawaiianPizzaBuilder();

You use

waiter.PizzaBuilder = new PizzaDatabaseBuilder("Hawaiian");

Second problem is I want the builder methods to actually create the parts then assign them to the product, not pass strings but real strongly typed product parts.

Should not be an issue. What you need is an other Factory/Builder type pattern to initialize the fields of the Pizza. For example

instead of

 public override void BuildDough()   { pizza.Dough   = "pan baked"; }

you would do something like

 public override void BuildDough()   { pizza.Dough   = new DoughBuilder("pan baked"); }

or

 public override void BuildDough()   { pizza.Dough   = new PanBakedDoughBuilder(); }

DoughBuilder can go to another table in your database to properly fill out a PizzaDough Class.

Answer 2

Mostly the call of a BuilderPattern looks like this:

Car car = new CarBuilder().withDoors(4).withColor("red").withABS(true).build();

Answer 3

I've never thought about it this way, but LINQ (the pattern, not the syntax) is actually a builder, right?

It's a fluent interface that builds a query and can create queries in different representations (SQL, in-memory object queries, webservice queries, Bart de Smet even wrote an implementation of Linq-to-Excel).

Answer 4

I would say that you cannot avoid either of these - having few overloads for your parts and having a case/if statement somewhere down the stack. Also having to modify your code when adding new class might be your only option.

That being said you can get help with some other patters - namely Factory that could aid you in the building process. Also sensible use of polymorphism (e.g. all parts inherit from the some type be it class or interface) can reduce the amount of ifs/cases and overloads.

Hope this helps.