浅谈设计模式:builder pattern

最近工作比较轻松，应同事邀请 让我给研发部的所有同事 讲解spring3.0+struts2.0的整合 （因为我们研发部 大部分都是做net的） 我幸苦准备一下午的 ppt  却突然听大师说  spring 有什么意思嘛  还不如跟我搞 服务

ok 我转身就跟大师写服务去了 并顺手 删了ppt

前天 同事又在提这样事 问我ppt 写好没 什么时候开讲？

哦 天啦 大师不是说没意思的嘛 我都删掉了

“你个笨蛋 大师的话 你也听  大师什么级别的人物 他当然 看不上了”

天 再次被大师忽悠了

设计模式 我以前搞过 不过 也是 偶尔 现在时间多  充电吧

首先 第一个 建造者模式

builder pattern

概述:

在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。

现实中的例子:

就拿学校来说吧,每到期末考试完成之后,老师要批改试卷,得到每个学生的期末考试成绩,而老师批改试卷这个过程不变化的,都要经过（批改试卷、统计分数、把分数上传到教务处）。每个老师都要经过这样一个步骤，而变化是其中的子过程，如：批改的是《英语》或者《数学》，统计分数的时候，可以将分数记录到纸张上，也可以用一个EXCEL文档保存起来等等。

我们先看其结构

意图：     

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

实用性;

当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

当构造过程必须允许被构造的对象有不同的表示时.

其中的类或对象之间的关系为：

      Builder:抽象建造者

　    为创建一个Product对象的各个部件指定抽象接口。

      ConcreteBuilder:具体建造者

       1.实现Builder接口，构造和装配产品的各个部件.

       2.定义并明确它所创建的表示.

       3.提供一个返回这个产品的接口。

      Director:指挥者

　　     构建一个使用Builder接口的对象。

      Product:产品角色

        1.被构建的复杂对象，具体建造者创建该产品的内部表示并表示定义它的装配过程。

        2.包含定义组成部件的类，包括将这些部件装配成最终产品的接口。

效果:

1、建造者模式的使用使得产品的内部表象可以独立的变化。使用建造者模式可以使客户端不必知道产品内部组成的细节。

2、每一个Builder都相对独立，而与其它的Builder无关。

3、可使对构造过程更加精细控制。

4、建造者模式的缺点在于难于应付“分步骤构建算法”的需求变动。

 总结：

　　建造者模式的实质是解耦组装过程和创建具体部件，使得我们不用去关心每个部件是如何组装的。