建造者模式（Builder ）

总述：  

把构造对象实例的逻辑移到了类的外部，在这个类外部定义了这个类的构造逻辑。
它把一个复杂对象的构造过程从对象的表示中分离出来。其直接效果是将一个复杂的对象简化为一个比较简单的对象。
它强调的是产品的构造过程。
在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定。
如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。
从而保持系统中的“稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。

意图：

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

 

产品类：一般是一个较为复杂的对象，也就是说创建对象的过程比较复杂，一般会有比较多的代码量。在本类图中，产品类是一个具体的类，而非抽象类。实际编程中，产品类可以是由一个抽象类与它的不同实现组成，也可以是由多个抽象类与他们的实现组成。
抽象建造者：引入抽象建造者的目的，是为了将建造的具体过程交与它的子类来实现。这样更容易扩展。一般至少会有两个抽象方法，一个用来建造产品，一个是用来返回产品。
建造者：实现抽象类的所有未实现的方法，具体来说一般是两项任务：组建产品；返回组建好的产品。
导演类：负责调用适当的建造者来组建产品，导演类一般不与产品类发生依赖关系，与导演类直接交互的是建造者类。一般来说，导演类被用来封装程序中易变的部分。

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

 就像一架风扇，组装过程基本上变化不大，一个是引擎，二个扇叶

这时候我们可以通过引导着负责组装这样的过程，然后我们在具体的每个部分可以时抽象接口,根据不同的实现创建不同的引擎或扇叶来完成变化。

 

// Builder pattern -- Real World example

using System;
using System.Collections.Generic;

namespace DoFactory.GangOfFour.Builder.RealWorld
{
   
    public class MainApp
    {
       
        public static void Main()
        {
            FanBuilder builder;

           
            Shop shop = new Shop();

          
            builder = new Fan1Builder();
            shop.Construct(builder);
            builder.Fan.Show();


            
            Console.ReadKey();
        }
    }

    /// <summary>
    /// The 'Director' class
    /// </summary>
    class Shop
    {
        // Builder uses a complex series of steps
        public void Construct(FanBuilder FanBuilder)
        {
            FanBuilder.BuildFlabellum();
            FanBuilder.BuildEngine();
         
        }
    }

    /// <summary>
    /// The 'Builder' abstract class
    /// </summary>
    abstract class FanBuilder
    {


        // Gets Fan instance
        public Fan Fan;
       

        // Abstract build methods
        public abstract void BuildFlabellum();
        public abstract void BuildEngine();
     
    }

    class Fan1Builder : FanBuilder
    {
        public Fan1Builder()
        {
             Fan = new Fan();
        }



        public override void BuildFlabellum()
        {
            this.Fan["Flabellum"] = "3";
        }

        public override void BuildEngine()
        {
            this.Fan["Engine"] = "1100r/min";
        }
    }


    class Fan2Builder : FanBuilder
    {
        public Fan2Builder()
        {
            Fan = new Fan();
        }
        public override void BuildFlabellum()
        {
            this.Fan["Flabellum"] = "4";
        }

        public override void BuildEngine()
        {
            this.Fan["Engine"] = "2200r/min";
        }
    }

    /// <summary>
    /// The 'Product' class
    /// </summary>
    class Fan
    {
      

        private Dictionary<string, string> _parts =
         new Dictionary<string, string>();

       

      
        public string this[string key]
        {
            get { return _parts[key]; }
            set { _parts[key] = value; }
        }

        public void Show()
        {
            Console.WriteLine("\n---------------------------");

            Console.WriteLine(" Engine : {0}", _parts["Engine"]);
            Console.WriteLine(" Flabellum : {0}", _parts["Flabellum"]);
          
        }
    }
}

 

建造者模式的优点

        首先，建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。

        其次，建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。

 

建造者模式与工厂模式的区别

       我们可以看到，建造者模式与工厂模式是极为相似的，总体上，建造者模式仅仅只比工厂模式多了一个“导演类”的角色。在建造者模式的类图中，假如把这个导演类看做是最终调用的客户端，那么图中剩余的部分就可以看作是一个简单的工厂模式了。

       与工厂模式相比，建造者模式一般用来创建更为复杂的对象，因为对象的创建过程更为复杂，因此将对象的创建过程独立出来组成一个新的类——导演类。也就是说，工厂模式是将对象的全部创建过程封装在工厂类中，由工厂类向客户端提供最终的产品；而建造者模式中，建造者类一般只提供产品类中各个组件的建造，而将具体建造过程交付给导演类。由导演类负责将各个组件按照特定的规则组建为产品，然后将组建好的产品交付给客户端。

总结

       建造者模式与工厂模式类似，他们都是建造者模式，适用的场景也很相似。一般来说，如果产品的建造很复杂，那么请用工厂模式；如果产品的建造更复杂，那么请用建造者模式。