title: Design Pattern: Builder
body: <p>I have looked for a <strong>good</strong> example of a <strong>Builder pattern</strong> (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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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).</p>