近期的心得，我发现学一门设计模式，无论你能否立马理解它，第一最要紧的是要记住两个东西。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();
}
}
// client使用：
class Main {
public static void main(String[] args) {
// 对于client而言，仅仅须要关心详细的建造者，无需关心产品内部构建流程。我假设须要其它的复杂产品对象。仅仅须要选择其它的建造者，假设须要扩展，则仅仅须要写一个新的builder即可。假设能够，这个建造者甚至能够用配置文件做。添加很多其它的扩展性。
Builder builder = new ConcreteBuilder();
// 把建造者注入导演
Director director = new Director(builder);
// 指挥者负责流程把控
director.construct();
// 建造者返回一个组合好的复杂产品对象
Productor productor = builder.getProductor();
}
}
不知道大家在此有否发现，上面的样例。通过使用建造者模式，建造过程通过Director的construct的方法固定下来了。
建造过程不会变。但详细的部位，头，身体。脚的表现方式。让详细的builder去实现了。这样不仅使得小人的建造过程不变。并且有利于功能的扩展。
3、使用建造者模式的优点
1.使用建造者模式能够使client不必知道产品内部组成的细节。
2.详细的建造者类之间是相互独立的，对系统的扩展很有利。
3.因为详细的建造者是独立的，因此能够对建造过程逐步细化。而不正确其它的模块产生不论什么影响。
4、使用建造者模式的场合:
1.创建一些复杂的对象时，这些对象的内部组成构件间的建造顺序是稳定的，可是对象的内部组成构件面临着复杂的变化。
2.要算法创建复杂的对象。独立对象的一部分，也独立的组件部分的组合物的。
版权声明：本文博客原创文章，博客，未经同意，不得转载。