设计模式:生成器

时间:2009-03-30 04:52:35

标签: c# design-patterns interface-builder builder

我已经找到构建器模式的良好示例(在C#中),但找不到,因为我不了解Builder模式或我是试图做一些从未打算过的事情。例如,如果我有一个抽象的汽车和抽象的构建方法来创建汽车零件,我应该能够将所有30个选择发送给Director,让它构建我需要的部件,然后构建我的汽车。无论生产哪种汽车,卡车,半卡车等,我都应该能够以完全相同的方式“驾驶”它。

第一个问题是大多数示例硬编码属性值到具体部分,我认为应该来自数据库。我认为这个想法是将我的选择发送给Director(来自数据源)并让构建器根据我的数据创建自定义产品。

第二个问题是我希望构建器方法实际创建部件然后将它们分配给产品,而不是传递字符串,而是真正的强类型产品部件。

例如,我想通过为我创建一个Builder制造表单字段来动态创建表单,包括标签,输入部分,验证等。这样我就可以从我的ORM中读取对象,查看对象的元数据,将其传递给我的Builder并将新创建的用户控件结果添加到我的Web表单。

但是,我发现的每个Builder示例都只有硬编码数据,而不是将选择从主代码传递到Builder并开出定制产品。一切似乎都是一个很大的静态案例陈述。例如,如果我有三个参数,每个参数有10个选项,我不想构建30个具体的Builder方法,我想创建的只是足以制作我的产品所需的属性,可能只有三个。

我很想让Director只存在于主代码中。应该有一种方法可以自动确定调用哪个具体的构建器方法,类似于多态和方法重载(尽管这是一个非常糟糕的例子),而不是在模式中使用case语句。 (每次我需要添加新的产品类型时,我都需要修改现有的Director,这很糟糕。)

4 个答案:

答案 0 :(得分:21)

主要是BuilderPattern的调用如下所示:

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

答案 1 :(得分:14)

我从未想过这样,但LINQ(模式,而不是语法)实际上是一个构建者,对吗?

这是一个流畅的界面,可以构建查询,并可以用不同的表示形式创建查询(SQL,内存中对象查询,Web服务查询,Bart de Smet甚至编写了L​​inq-to-Excel的实现)。

答案 2 :(得分:11)

我将参考维基百科文章here中的C#示例。

  

第一个问题是大多数示例硬编码属性值到具体部分,我认为应该来自数据库。我认为这个想法是将我的选择发送给Director(来自数据源)并让构建器根据我的数据创建自定义产品。

在这种情况下,您将拥有实现PizzaBuilder的类,该类知道如何从数据库中检索数据。你可以用几种方法做到这一点。

一个人将成为HawaiianPizzaBuilder。当类初始化时,它会在数据库中查询Hawaiian Pizza并检索该行。然后,当调用各种Build(x)方法时,它会将属性设置为检索到的数据库行的相应字段。

另一个只是制作一个PizzaDatabaseBuilder,并确保在初始化类时,您传递了该类比萨饼所需的行ID。例如,而不是

waiter.PizzaBuilder = new HawaiianPizzaBuilder();

您使用

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

第二个问题是我希望构建器方法实际创建部件然后将它们分配给产品,而不是传递字符串,而是真正的强类型产品部件。

应该不是问题。您需要的是另一个Factory / Builder类型模式来初始化Pizza的字段。例如

而不是

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

你会做类似

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

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

DoughBuilder可以转到数据库中的另一个表来正确填写PizzaDough类。

答案 3 :(得分:0)

我会说你无法避免这些 - 你的零件几乎没有重载,并且在堆栈的某个地方有一个case / if语句。在添加新课程时也必须修改代码可能是您唯一的选择。

据说你可以得到其他一些模式的帮助 - 即可以帮助你建造过程的工厂。同样明智地使用多态(例如,所有部分都继承自某种类型,无论是类还是接口)都可以减少ifs / case和overres的数量。

希望这有帮助。