设计模式复习（五）-------建造者模式

1.定义

建造者模式可以将部件本身和它们的组装过程分开，关注如何一步步创建一个包含多个组成部分的复杂对象，用户只需要指定复杂对象的类型即可得到该对象，而无须知道其内部的具体构造细节。

将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。 —《设计模式》GoF

在软件系统中，有时候面临着“一个复杂对象”的创建工作，复杂对象由各个部分的子对象用一定的算法构成； 由于需求的变化，复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。

如何应对这种变化？

如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？

对象相当于一个待建造的产品，而对象的属性相当于产品的零件，建造产品的过程就是组合零件的过程：由于过程很复杂

过程：客户端负责创建指导者和具体建造者对象。然后，客户把具体建造者对象交给指导者。客户一声令下，指导者操纵建造者开始创建产品。当产品创建完成后，建造者把产品返还给客户端。

2.结构

建造者（Builder）角色：给出一个抽象接口，以规范产品对象的各个组成成分的建造。一般而言，此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者（ConcreteBuilder）角色。具体建造者类必须实现这个接口所要求的方法：一个是建造方法，另一个是结果返还方法。具体建造者（Concrete Builder）角色：担任这个角色的是与应用程序紧密相关的类，它们在应用程序调用下创建产品实例。这个角色主要完成的任务包括： 实现Builder角色提供的接口，定义产品对象，一步一步（零件）完成创建产品实例的过程。 在建造过程完成后，提供产品的实例（完整产品）。指导者（Director）角色：担任这个角色的类调用具体建造者角色以创建产品对象。指导者并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者对象。产品（Product）角色：产品便是建造中的复杂对象。 指导者角色是与客户端打交道的角色。指导者将客户端创建产品的请求划分为对各个零件的建造请求，再将这些请求委派给具体建造者内部的具体方法。具体建造者角色是做具体建造工作的，但却不为客户端所知。

具体的构建者可以有多个，它们都继承自Builder父类（或实现这个接口）

3.实例

这个得好好写写，上课走神了…

游戏中构建一座房子时，房子的构成和构建步骤通常是稳定不变的，但是房子的风格要经常变化，因此这样的的房子的构建可以选用建造者模式。 （示例–GameHouseBuilder） Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法（即Director，如上面例子中的GameManager），而复杂对象的各个部分（即ConcreteBuilder）则经常变化。 AbstractFactory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。Builder模式通常和Composite（组合）模式组合使用。

老师给的源码是用C#写的不带配置文件的，我再添加两句

项目工程结构：

/* 抽象建造者Builder */ namespace GameHouseBuilder { //抽象建造者，规定构建的基本构件和搭建过程 public abstract class Builder { //房屋的部分构造器 public abstract void BuildWall(); public abstract void BuildDoor(); public abstract void BuildWindow(); public abstract void BuildFloor(); public abstract void BuildCeiling(); //获取构建好的房屋--零件组合过程隐含于其中--此过程应该稳定 public abstract House GetHouse(); } } /* 1.具体建造者ClassicalHouseBuilder，还有一个具体构建者代码不贴了 2.在实际项目中，下面的打印语句实际上是为对象添加属性，然后给客户端返回一个按要求封装好的对象； 3.按照建造者模式的定义，客户端指导建造者只是下达一个建造命令，即可得到一个封装好的对象，客户端对建造者中的具体知识并不了解，具体的构件过程由指导者指导 4.另外因为没有具体的业务逻辑要求，实体类House的属性没有被定义 */ namespace GameHouseBuilder { /// <summary> /// 具体的创建者类 /// </summary> public class ClassicalHouseBuilder : Builder { private House house=null; //要构建的具体的产品对象 //房屋的部分构造器 public override void BuildWall(){ Console.WriteLine("构建古典型的墙"); } public override void BuildDoor(){ Console.WriteLine("构建古典型的门"); } public override void BuildWindow(){ Console.WriteLine("构建古典型的窗户"); } public override void BuildFloor(){ Console.WriteLine("构建古典型的地板"); } public override void BuildCeiling(){ Console.WriteLine("构建古典型的天花板"); } //搭建房屋，然后获取构建好的房屋 public override House GetHouse() { //具体组装...... Console.WriteLine("\n返回建造好的古典型的房屋\n"); return house; } } } namespace GameHouseBuilder { /// <summary> /// 建造者模式中的Director，负责管理创建对象的具体过程 /// </summary> public class GameManager { public static House CreateHouse(Builder builder) //biulder为具体的创建者对象 { //零件的构建过程--以下的构建过程相对稳定， 否则不能使用建造者模式 builder.BuildWall(); builder.BuildWall(); builder.BuildWall(); builder.BuildWall(); builder.BuildDoor(); builder.BuildDoor(); builder.BuildWindow(); builder.BuildWindow(); builder.BuildCeiling(); builder.BuildFloor(); //零件的构建过程--如果以上构建过程不稳定，则Builder模式就不适用了 return builder.GetHouse(); //创建完毕各个部分后， 组装--〉返回完整的对象 } } } <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key ="builder" value ="RomanticHouseBuilder"/> </appSettings> </configuration> /* 反射机制需要用到下面两个类库，不要忘了引入; 具体的反射实现细节跟上午用Java做的差不多，也是读取配置文件->拼出全类名->利用反射机制创建对象 这样就做到了完全解耦，以后如果需求再变化，比如加一种新的房屋样式，原来的源码一点也不用改。 */ using System.Reflection; using System.Configuration; namespace GameHouseBuilder { class Program { static void Main(string[] args) { Builder builder; string builderType = ConfigurationSettings.AppSettings["builder"]; builder = (Builder)Assembly.Load("GameHouseBuilder").CreateInstance("GameHouseBuilder." + builderType); //构建具体构造器对象 //也可以利用反射机制避免更改此处代码 //Builder builder = new ClassicalHouseBuilder(); //Builder builder = new RomanticHouseBuilder(); //客户程序只需要调用Director的方法就可以方便的构建对象，更改对象类型只需要改动具体构造器类型 House house = GameManager.CreateHouse(builder); //利用House对象作其他操作 //house.xxx(); Console.ReadLine(); } } }

4.优点

客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。每一个具体建造者都相对独立，与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，扩展方便，符合开放/封闭原则；可以更加精细地控制产品的创建过程。

5.缺点

建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，不适合使用建造者模式，因此其使用范围受到一定的限制；

分步骤构建算法（包括零部件的构建与组合，即Director和Builder）如果不稳定，则不适合；

如果产品的内部变化复杂，可能会需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大，增加了系统的理解难度和运行成本。

6.建造者模式的适用环境

需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员变量；需要生成的产品对象的属性相互依赖，需要指定其生成顺序；

下一轮复习的时候做做这个题：

4、计算机组装工厂可以将CPU、内存、硬盘、主机、显示器等硬件设备组装在一起构成一台完整的计算机，且构成的计算机可以是笔记本，也可以是台式机，还可以是不提供显示器的服务器主机。对于用户而言，无须关心计算机的组成设备和组装过程，工厂返回给用户的。是完整的计算机对象，使用建造者模式实现计算机组装过程，要求绘制类图并使用C#代码编程模拟实现。