C#面向对象设计模式纵横谈4 Builder生成器模式创建型模式

Buider生成器（创建型模式）

Builder模式的缘起
假设创建游戏中的一个房屋House设施，该房屋的构建由几个部分组成的，且各个部分要富于变化。
（面向对象设计模式解决的最重要问题应对变化，封装变化。）
如果使用最直观的设计方法，每一个房屋部分的变化，都将导致房屋构建的重新修正。

需求变化：能够预计到需求中哪些地方是变化的，封装变化点。

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

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

意图（Intent）
将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

public abstract class House{}public abstract class Door{}public abstract class Wall{}public abstract class Windows{}public abstract class Floor{}//高层抽象部分public abstract class Builder{    //屋子的各个部分    public abstract void BuildDoor();    public abstract void BuildWall();    public abstract void BuildWindows();    public abstract void BuildFloor();    public abstract void BuildHouseCeiling();    //最后要的是屋子    public abstract House GetHouse();}//这是另外一个类public class GameManager{    public static House CreateHouse(Builder builder)    {        //这个部分是稳定的。        builder.BuildDoor();        builder.BuildDoor();        builder.BuildWall();        builder.BuildWindows();        builder.BuildWindows();         return builder.GetHouse();    }}//罗马风格的房屋public class RomanHouse:House{}public class RomanDoor: Door{}public class RomanWall:Wall{}public class RomanWindows:Windows{}public class RomanFloor:Floor{}public class RomanHouseBuilder:Builder{    //屋子的各个部分    public override void BuildDoor()    {       }    public override void BuildWall()    {       }    public override void BuildWindows()    {       }    public override void BuildFloor()    {       }    public override void BuildHouseCeiling()    {       }    //最后要的是屋子    public override House GetHouse()    {           //房子的组合方式    }}//客户程序class App{    public static void Main()    {        Hourse hourse=            GameManager.CreateHouse(new RomainHouseBuilder());    }}//客户程序2(这种写法程序都不需要改变，只需要改变配置文件)class App2{    public static void Main()    {        string assemblyName=ConfigurationSettings["BuilderAssbmly"];        string builderNmae=ConfigurationSettings["BuilderClass"];        Assembly assembly=Assembly.Load(assemblyName);        Type t=assembly.GetType(buliderName);        Builder builder=Activator.CrateInstance(t);             Hourse hourse=GameManager.CreateHouse(builder);    }}

房屋的构建过程是一个高层的抽象，而房屋的地板，房顶等这些实现细节依赖于高层抽象，而不是高层抽象依赖于实现细节。高层抽象的部分相对稳定。

Builder模式的几个要点
Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。

变化点在哪里，封装哪里——Builder模式主要在与应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。

Abstract Factory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。Builder模式通常和Composite模式组合使用。

没有变化的需求就不要使用设计模式。
同样的问题，如果你静态的看，看不出设计模式的价值，但是你动态的看你的这些问题在需求的一步步变动过程中，你这个问题是怎么变的。这时候就能看出设计模式的价值了。