设计模式面面观（6）：生成器模式（Builder）-创建型模式
重要声明：
故事纯属虚构，如有雷同请勿对号入座，故事只是为了抛砖引玉，虽以第一人称和作者本人网名起但不代表本人真实想法，请勿把故事中人物和作者本人联系起来，故事本意只为模式创造前提条件
剧情：
最近家里刚刚装上宽带，那个高兴啊，终于不用天天泡在网吧里了，可是没高兴多长时间发现家里闹起了电脑慌，女朋友跟我强着上就一台电脑，还是本本没办法和女友合计买太电脑，但手头不宽裕放弃了买品牌电脑，于是呼就转悠了一圈组装电脑大卖场。吼吼这里什么都有，自己想怎么样装就怎么样装。于是两人坐到一店里，服务员给我拿来了配置
1. 华塑的主板
2. DELL的机箱
3. 三星的显示器
4. 不知名的2.0影响
（不全只是罗列一些）
选了一大通厚决定买了花了4500元钱，不一会服务员就把机器装好了，交完钱把电脑扛回家这回没有人再抢电脑了。
故事虽说简单，但这里却能很好的描述我们今天所讲的模式（生成器模式），我们来看下电脑这个类，他本身是由多个零部件组成的一个组成品，有主板啊，机箱啊等等他们都是独立的个体，再一起组成了一个更强大的机器。而卖组装电脑的点就像一个组装厂一样把各个零部件按顺序的组合起来，并使电脑能正常的运行。
我们来看看我如何用OOD来描述
<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 414.75pt; HEIGHT: 336pt" type="#_x0000_t75"><imagedata o:title="BuilderPatternt" src="file:///C:%5CDOCUME~1%5CFANWEI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.jpg"></imagedata></shape>
结构：
l Product （产品- Competor (电脑)）包含了（主版-MainBoard、显示器-Display、音响- Acoustics、光驱-ComboDVD）
l Director (ConputerDirector)
l Builder (ComputerDealer)
l ConcreteBuikder (DLLDealer、QIXIDealer)
判定这个OOD设计是否合理我们依据我们第二章的设计模式原则来判定
1. 是否符合开闭原则
封闭对组装电脑的步骤，开放多种电脑的组装。
答案：符合
2. 是否符合里氏代换原则
我们在单独主张一台DLL电脑的时候直接调用DLLDealer类即可，不需要调用他的抽象父类所以符合
答案：符合
3. 是否符合合成复用原则
电脑有多种硬件组成所以有些部件不可缺有些可以不要照样工作，不如音响其他的是必不可缺的，他们都有自己的名称价格等与生俱来的属性。
答案：符合
4. 是否符合依赖倒置原则
从这个类调用来看创建一台电脑主要靠的是ComputerDealer这个抽象类，所以Builder依赖与ComputerDealer
答案：符合
5. 是否符合接口隔离原则
本模式没有涉及到接口
答案：不涉及
6. 是否符合抽象原则
答案：符合
7. 是否符合迪米特法则
我们看到ComputerDealer只做组装电脑，返回电脑类的工作所以符合。
答案：符合
总的来讲这个OOD设计是符合设计模式的要求
总结 ：生成器模式
意图：
对一复杂对象的构造与他的表示分离，可使同样的构造过程创建出不同的表示。
复杂对象----电脑
同样的构造过程---都是用的同样接口创建
创建出不同的表示---我们用DLLDealer、QIXIDealer创建出DLL电脑和QIXI电脑
动机：
在软件系统中，当我们遇到一个复杂的对象是由多个独立的类通过一定的算法构成，又由于需求的变化使各个部分不断的变化（就像电脑中的显示器我可以用三星纯平的也可以用液晶的）组合后变成不同的同类型产品。但他们的组成算法通常是相对稳定的时候我们就可以用生成器模式
实用性：
l 一个系统要独立于他的产品的创建、组合和表示时（即客户不关心产品的生产过程只关心产品的使用是否合适）
l 一个系统要求多个产品系列中的一个来配置时（这个不难理解试想下Helen的要求就可以理解了）。
l 当你要强调一系列相关的产品对象的设计以便进行联合使用时
l 当你提供一个产品类库，只想显示他们的接口而不是现实时（这个在软件开发中相当重要，尽量减少软件对外的接口可以更好的保护软件的安全性）
适用性：
l 当创建的对象的算法应该独立与该对象的组成部分以及他们的装配方式时
l 当构造过程必须允许被构造的对象有不同的表示时
结构：
<shape id="_x0000_i1026" style="WIDTH: 318pt; HEIGHT: 134.25pt" type="#_x0000_t75" alt=""><imagedata src="file:///C:%5CDOCUME~1%5CFANWEI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image003.gif" o:href="http://www.cnblogs.com/images/cnblogs_com/zhenyulu/Pic53.gif"><font size="3"></font></imagedata></shape>
参与者：
l Product （产品- Competor (电脑)）包含了（主版-MainBoard、显示器-Display、音响- Acoustics、光驱-ComboDVD）
l Director (ConputerDirector)
l Builder (ComputerDealer)
l ConcreteBuikder (DLLDealer、QIXIDeal)
效果：
1. 可以是你任意改变产品部件的内部表示
2. 将构造代码和表示代码分开（可参见源代码）
3. 更好的控制产品的构造过程
代码：