Builder 生成器模式

     实际上，既然Builder和Factory同属创建型模式，那么他们的最大共同点就在于都可以创建类对象，在这点上，不光这两个模式一样，其它创建型模式也一样。但正如在《深入探索Factory模式与Prototype模式的异同(续)》一文中所说，这些模式，功能上的相似，只是“形似而非神似”。既然这样，那好，下面就让我们能看看Builder和Factory在功能的相似上，存在哪些神韵方面的差别。

 

     首先，也是最重要的一点，就是虽然Builder和Factory都可创建产品，但两者所创建的产品类型完全不一样。Factory创建只能是单一的产品(单一在这指它非复合产品),而Builder所创建的产品是复合产品，即产品本身就是由其它部件产品组成的。

 

     举个例子来说，现在要生产一辆车，假设它就只由这三个部分组成：玻璃、轮子、发动机。对于工厂模式来说，他创建后返回的，只能是玻璃，或者轮子，抑或是发动机。不管怎么样，他不能向客户返回一辆完整的汽车，要得到一辆完整的汽车，客户必须自己动手去把这些零部件组装成一辆汽车。从这个意义上来讲，工厂模式中的工厂，只是充当了零件厂的角色。那Builder又是如何创建产品的呢？在Builder模式中，一般不需要、也不充许向客户返回单个部件，他向客户返回的，仅仅就是一部已经完全组装好的汽车成品。对于汽车部件的生产细节，客户不需要、也不应该让他们知道。写到这，我突然想到了组装电脑与品牌电脑的差别，组装电脑虽然价格便宜，且易于改动，但性能没有保证，另外你自己还必须了解很多有关电脑方面的知识；对于品牌电脑，价格贵这点先暂时不说，关键在于他不灵活，但是它的性能可以得到很好保证(由厂家)，这易像我们在Builder的系统端保证部件的质量一样。另外，对于品牌电脑，客户根本不需要了解多少电脑组装方面的知识，就可以把一台电脑抱回家，开机使用了。那么，在实际运用中，你是喜欢做DIY一族呢，还是喜欢稳定有保证的质量呢？好像在我们编著程的这个过程中，我们比较趋向于使用“品牌电脑”。这也就为我们正确使用这两种设计模式提供了一个方向：如果你要生产的产品是由不同部件组成的，你最好使用Builder模式，而非Factory模式。

 

     另外，Builder和Factory的差别，就在于他们所生产部件产品所在产品树的问题。这样说，可能有点拗口。具体来说吧，在工厂模式中，我们知道，一个工厂可以创建多个产品，但一个工厂模式中所创建的某个产品，都会和另一个工厂中所创建的产品在同一棵继承树上。如果大家看过我最早写的《用Java实现的设计模式系列（1)—Factory 》那篇文章,就会记得，我在CFactoryMac中创建了一种产品叫MacRam,而在CFactoryWin中创建了另一种产品叫WinRam,很显然，这两种产品是在同一棵继承树上的。对于它们之所以会出现在同一棵继承树上，是完全由Factory模式本身所决定的。大家如果看过Factory的UMl图，就应该记得，要实现Factory模式，一定要有一个Abstract Product类，具体产品再由它派生出来。好了，说完了Factory,再让我们来看看Builder中是否必这么做！实际上，在Builder模式中，我们只是在Abstract Builder中封装了创建部件的接口，而具体创建了什么部件，不同的实际Builder可能会生产出完全不一样的部件，这样不会存在任何问题，因为，我上面说过，Builder只是向客户返回成品，而不向客户返回具体部件，这样，当然就允许产品的部件按要求随意变化了。

 

     再举个例子吧，假如你现在要创建两种风马不相及的东西，例如一种是人，它就只由这几部分组成：脑、身、四肢；另一种是树，也由三个部分组成：根、叶、茎。

 

 

本文出处：http://blog.csdn.net/blackphoenix/archive/2002/08/20/14154.aspx

评论

1 楼 csdn_zuoqiang 2010-08-12  

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。



当一个复杂对象的创建需要很多步骤的时候,这些步骤在不同的条件下是变化的.通过不同的Builder创建'不同风格'的复杂对象.



为什么不用类本身的constructor呢,构造函数应该只是对本身的数据(state&data)进行初始化.



Builder的buildPart可以在ConcreteBuilder被override,不同的ConcreteBuilder的buildPart不同,从而

得到不同的product.







客户端代码通过使用不同ConcreteBuilder,得到不同规格的产品.

Builder builder = new ConcreteBuilder();  //这个地方也可根据外部配置文件进行反射.
Director director = new Director( builder );        
Product product = builder.getResult();



Builder 和Factory有什么区别呢,我们包Builder简化,去掉Director,发现其和简单Factory就一样了.



为什么有了Factory还要有Builder呢,客户端无非都是得到想要的product啊?不理解......,目前的理解是:



Builder:分步骤的,构建出一个复杂对象,这个复杂对象有很多parts,在不同的场景中,part可能不同.

e.g. 一座房子,有屋顶,门,天花板,地板.

房子A的屋顶是欧式的斜顶,门是木门,天花板也是木的,地板也是木的.

房子B的屋顶是平顶的水泥板,门是防盗门,天花板是吊顶的,地板是木的.

它们的组成过程一样,每一个parts不同.



Simple Factory:构建简单对象,在不同的场景中,这个对象的实现可能不一样.

e.g. 保存数据的一个类,都有save方法.

类A的save方法把数据保存到DB.

类B的save方法把数据保存到File.

客户端通过factory得到一个这种类的对象,不关心是类A还是类B,调用save就行了.



Abstract Factory:构建系列对象,对象间有关联,不同的场景关联不同.

有一个factory,创建两个不同的task,task1和task2.

factoryA创建的task1要在task2之前完成.

factoryB创建的task1要在task2之后完成.

(parts不同,更关注这个对象的组成,实现不同,更关注这个对象的行为.)



其实,客户端本来就不关心你用的是Builder,Factory,Abstract Factory,只有你保证客户端代码不用改就行了.