设计模式——建造者

最近的心得，我发现学一门设计模式，不管你是否能立刻理解它，第一最要紧的是要记住两个东西。 1、它是属于什么范畴的设计模式。2、记住UML图。 这两个是打开这个设计模式之门的金钥匙！为什么这么讲？因为刚刚学新的设计模式，如果一味的埋头在文字中，思想中，代码编写的例子中，如果你这个设计模式又不是看的很懂，实在是会让人晕头转向看的吐血身亡。结果在身亡前，你都不知道这个设计模式干什么用，也不知该怎么去写。心得是，看完一篇设计模式文章，先记住它属于什么范畴的设计模式，然后就是把UML类图背记下来。再然后回头再看一遍，这样你可能就慢慢懂了些。也能很快的通过uml图编写出代码来。即便此时你不是很深刻的理解他。因为设计模式，无非就是设计出这样的类的关系来，所以记住了范畴和uml类图，不管三七二十一，碰到这个需求，先按照这样的关系来设计。久而久之，你就能越来越明白这个设计模式的精髓到底是什么了。

    好，今天讲的是建造者。

    1、认识建造者
    建造者模式属于创建型模式（先记下）。顾名思义，builder的意思是建造者或者建筑工人。例如：楼房是千差万别的，楼房的外形，层数，内部房间的数量，房间的装饰都不一样。但是对于建造者来说，抽象出来的建筑流程是确定的。因为建筑一座楼房，都可以归纳为几个步骤：1打桩、2建地基、3搭框架、4内部建设。同理，建造者设计模式也是基于这样的概念而生的，这个设计模式用来解决什么样的情况呢：即流程不变，但每个流程实现的具体细节是会变化的。这样的情况，可以考虑使用建造者。就像盖房子，4个流程都必须有，但每个流程各自的实现细节，各个房子各有不同。建造者模式的好处就是保证了流程不会变化，即流程不会增加也不会遗漏，也不会产生流程次序的错误。这是非常重要的，看新闻，一些楼歪歪的事件，很多都是建设楼盘的时候，流程出现了问题导致的。（看来这些人并不知道建造者模式啊）。而建造者模式，保证了流程的确定性，而流程内部的实现细节，是可继承扩展的。从根源上解决了流程不规范的问题。

    福清有一道小吃叫海蛎饼，家家户户都会做，但各家各户做的味道都不同。虽然味道不同，但制作海蛎饼的流程步骤，大致都是一样的。一个成功的海蛎饼，外酥内嫩，滋味丰富。虽然口感各有不同，但只要流程步骤不差，都会做出好吃的海蛎饼。而一些刚嫁人的新媳妇们制作海蛎饼却不如婆婆好，因为新媳妇刚学做，不熟悉流程，难免流程常有疏漏。而如果让婆婆站在媳妇旁把控制作流程，海蛎饼就不会差。所以说，如果流程控制好了，生产出来的海蛎饼就不会差。

     写代码也是如此，如果你遇到一个需要把控流程，但流程中的实现细节各有许多的方式，你可以采用建造者模式。用一个director类把控流程，而用许多不同的builder去建造流程中的细节并产生产品。这样，生产出来的产品是绝对不会出问题的。因为流程把控好了。你可以有多个builder去负责建造生产产品，而让director去把控流程。如果有新的产品，但是流程一致，你可以再扩张出一个builder来。这样，你看，建造者模式是不是很符合OCP原则呢。

    说了这么多，来看下建造者模式的概念： 将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以有不同的表示。

    嗨，这个概念看起来总是这么深奥难懂。大概的意思，就是一套的构建过程可以有不同的产品（表示）出来。这些产品（表示）都按照这一套的构建过程被生产出来。

    建造者模式通常包括以下这几个角色：
    1、Builder：给出一个抽象接口，规范建造者对于生产的产品的各个组成部分的建造。这个接口只是定一个规范，不涉及具体的建造，具体的建造让继承于它的子类（ConcreteBuilder）去实现。
    2、ConcreteBuilder：实现builder接口，针对不同的商业逻辑，具体化各对象部分的建造，最后返回一个建造好的产品。
    3、Director：导演，顾名思义，负责规范流程之用。在指导中不涉及产品的创建，只负责保证复杂对象各部分被创建或按某种顺序创建。
    4、Product：复杂对象。
    按照惯例，给出建造者模式的UML图（这个先记下来，非常有用，学一个设计模式，先把这个图记下来！）
    


     2、一个建造者的实例。
    在此，以这篇文章作为参考 http://blog.csdn.net/lovelion/article/details/7426015 ，我们来做一个游戏的案例。
    游戏开发中，游戏角色是一个复杂的产品，它包括性别、脸型、身材等多个组成部分，不同的角色组成部分有所差异。如这张图：
    
    无论是何种类型的游戏的游戏角色，它的创建步骤都大同小异，都需要逐步创建其组成部分，再将各组成部分装配成一个完整的游戏角色。

    一个典型的复杂类对象代码示例如下：
    class Productor {
            private Part partA;
            private Part partB;
            private Part partC;

            // 这些是各个部件的set和get的方法，在此省略。。。
    }
    这是抽象的Builder：
    abstract class Builder {
            public abstract void buildPartA();
            public abstract void buildPartB();
            public abstract void buildPartC();
    }
    继承Builder的具体的建造者：
    class ConcreteBuilder extends Builder {
            private Product product;
            // 创建partA
            public void buildPartA() {
                    // 在此创建出部件
                    Part partA = new PartA();
                    // ......

                    // 把partA传递给product
                    product.setPartA(partA);
            }
            // 创建partB
              public void buildPartB() {
                        // 在此创建出部件
                        Part partB = new PartB();
                        // ......

                         // 把partB传递给product
                        product.setPartA(partB );
               }
            // 创建partC
              public void buildPartC() {
                        // 在此创建出部件
                        Part partC = new PartC();
                        // ......

                         // 把partC传递给product
                        product.setPartA(partC );
               }   
            // 返回复杂产品对象
            public void getProduct() {
                return this.product;
            }     
    }
    这是导演，负责流程规范，在导演类中可以注入建造者对象。
    class Director {
            private Builder concretebuilder;
            // 构造方法中也可以传递builder
            public Director(Builder builder) {
                    this. concretebuilder = builder;
            }
            // 传递builder
            public void setBuilder(Builder builder) {
                    this. concretebuilder = builder;
            }
            // 这个方法用来规范流程，产品构建和组装方法
            public void construct() {
                    builder.buildPartA();
                    builder.buildPartB();
                    builder.buildPartC();
            }
    }
    // 客户端使用：
    class Main {
            public static void main(String[] args) {
                    // 对于客户端而言，只需要关心具体的建造者，无需关心产品内部构建流程。我如果需要其他的复杂产品对象，只需要选择其他的建造者，如果需要扩展，则只需要写一个新的builder就行。如果可以，这个建造者甚至可以用配置文件做，增加更多的扩展性。
                    Builder builder = new ConcreteBuilder();
                    // 把建造者注入导演
                    Director director = new Director(builder);
                    // 指挥者负责流程把控
                    director.construct();
                    // 建造者返回一个组合好的复杂产品对象
                    Productor productor = builder.getProductor();
            }
    }
    不知道大家在此有否发现，上面的例子，通过使用建造者模式，建造过程通过Director的construct的方法固定下来了。建造过程不会变，但具体的部位，头，身体，脚的表现方式，让具体的builder去实现了。这样不仅使得小人的建造过程不变，而且有利于功能的扩展。

     3、使用建造者模式的好处
    1.使用建造者模式可以使客户端不必知道产品内部组成的细节。
     2.具体的建造者类之间是相互独立的，对系统的扩展非常有利。
     3.由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。

    4、使用建造者模式的场合:
     1.创建一些复杂的对象时，这些对象的内部组成构件间的建造顺序是稳定的，但是对象的内部组成构件面临着复杂的变化。
     2.要创建的复杂对象的算法，独立于该对象的组成部分，也独立于组成部分的装配方法时。