前面两篇文章中讨论一下创建型设计模式的工厂模式、抽象工厂模式、单例模式，今天就继续聊一聊创建型模式的剩下两种，Builder模式和Prototype模式。

1、Builder模式

何为Builder模式，其实Builder模式比较好理解，就是将一个复杂对象的创建过程分解成几个Step,而每个step又抽象出来。具体实现由每个子类自己来决定，在通过第三方的一个Driector类来实现组合Step的顺序以达到最终的创建这个复杂的对象。

具体可以见如下的图（from wiki）：

从图中，我们可以看到Director的Construct类用于将每个step构建起来，Builder中的buildPart()具体抽象了创建的过程由继承类ConcreteBuilder的BuilderPart()来实现具体的构建。最终构建一个完整的Product。

后面在聊一下结合其他设计模式的理解，关于Builder和Abstract Factory。Builder主要是构造整理里面的每一个part。而Abstract Factory则是为了为统一类的Product提够工厂。还有关于Build Part，个人倒是觉得可以结合工厂模式来做，这样将每个part的实现由和ConcreteBuilder解耦合了，例如通过注入的方式来表明具体的实现。

突然想到，如果能把各种设计模式用的游刃有余那该是多么happy的一件事啊。

2、Prototype模式

和builder模式一样，Prototype也同样非常好理解，你可能经常不经意间就用到了它。例如你已经有一个某个类的对象了，现在你需要创建一个和本对象相同的新对象。（请注意理解这里相同的意思哦）那该如何呢？基本上就会想到Clone()方法了。没错，clone()方法就是原型模式的实现。下面先看一下原型模式的结构图（from 大话设计模式）

在原型模式中一般会要处理的就是深浅拷贝的问题，其实关于深浅拷贝也是比较好理解的。以java为例，java的内存分为四快：堆、栈、代码区、数据区。对象的引用放在栈，对象放在堆。对于clone()毫无疑问，会重新开辟一个堆空间构建新对象。对于该对象的基本类型复制为原对象的值。那么对于类类型呢？有两种方式：一种是同样开辟一个空间存放该类类型（注意这是一个递归的过程），这就是所谓的深拷贝；还有一种则是只是引用指向原对象类类型的实例，此为浅拷贝。

关于深拷贝一定要注意就是，这是一个递归的过程。你必须保此类所包含的所有类（包括递归包含），都实现了深拷贝。还有就是要求父类对象也实现对象也实现了clone()方法，并完成深拷贝。而且在子类的clone()中调用super.clone()方法。

Ps:在java中一般实现Cloneable接口中的clone()方法即可。
pdf下载：/Files/zhenxuanpan/设计模式之Builder模式和Prototype模式.pdf


 

如果说道设计模式，我想大家想到最多的应该就是单例模式和工厂模式，上一篇文章中详细介绍了工厂模式以及简单工厂模式和抽象工厂模式。相对工厂模式，单例模式要简单一点，但是单例模式也同样有很多值得思考的问题，下面就来看一下这些问题以及解决的办法。

1、静态初始化实例对象（网上也有人叫饥饿实例化）

public class EagerSingleton {

    private static final EagerSingleton instance = new EagerSingleton();

    private EagerSingleton() {

    }

    public static EagerSingleton getInstance() {

        return EagerSingleton.instance;

    }

}

2、当第一次需要的时候创建实例化对象（懒汉实例化）

public class LazySingleton {

    private static LazySingleton instance = null;

    private LazySingleton() {

    }

    public synchronized static LazySingleton getInstance() {    

        if(instance == null) {

            instance = new LazySingleton();

        }

        return instance;

    }

}

这里一定要注意加synchronized,否则就会引进多线程下的不安全的情况了。

但是，考虑到synchronized加在方法上，锁的粒度太多，会对性能产生影响。所以引入下面的dcl算法进行改进。

3、采用dcl算法改进2（关于dcl请看这个http://en.wikipedia.org/wiki/Double-checked_locking，后面找时间详细聊聊这个东西，貌似是jee中一个很常用的东西）

public class DclLazySingleton {

    private static DclLazySingleton instance = null;

    private DclLazySingleton() {

    }

    public static DclLazySingleton getInstance() {

        if(instance == null) {

            synchronized(DclLazySingleton.class) {

                if(instance == null) {

                    instance = new DclLazySingleton();

                }

            }

        }

        return instance;

    }

}

ps:按照wiki的说法，这种算法是有问题，这个后面在讨论，不过貌似异常出现的概率很小，而且很多成功的开源项目都用到了它，所以，不用担心！

4、看到这里，是不是大家觉得单例模式就该解决了呢？可是有没有发现一个问题呢？上面的单例类都不能做父类，因为构造方法是私有的，ps，子类的构造方法默认会去调用父类的构造方法，如果是私有的，这个果断没法继承啊。

所以就引进了下面的注册式的单例实现方式。看网上很多人都说spring中使用了这种方式，所以开始了解这种方式，其实经典的GoF的书中就有对这个的介绍。

public class RegisterSingleton {

    private static Map<String, RegisterSingleton> instanceMap = new HashMap<String, RegisterSingleton>();

    static {

        RegisterSingleton instanceThis = new RegisterSingleton();

        instanceMap.put(RegisterSingleton.class.getName(), instanceThis);

    }

    protected RegisterSingleton() {

    }

    public static RegisterSingleton getInstance(String name) {

        if(name == null) {

            name = RegisterSingleton.class.getName();

        }

        if(instanceMap.get(name) == null) {

            try {

                instanceMap.put(name, (RegisterSingleton)Class.forName(name).newInstance());

            } catch (InstantiationException e) {

                e.printStackTrace();

            } catch (IllegalAccessException e) {

                e.printStackTrace();

            } catch (ClassNotFoundException e) {

                e.printStackTrace();

            }

        }

        return instanceMap.get(name);

    }

    public static RegisterSingleton getInstance() {

        return getInstance(RegisterSingleton.class.getName());

    }

}

使用重载来便捷的调用getInstance()方法。

子类如果继承去调用getInstance方法呢？请看如下代码：

public class RegisterSingletonChild extends RegisterSingleton {

    protected RegisterSingletonChild() {}

    public static RegisterSingletonChild getInstance() {

        return (RegisterSingletonChild)RegisterSingleton.getInstance(RegisterSingletonChild.class.getName());

    }

}

当然，如果子类确定没有子类的话，则可以考虑用private去替代protected.

5、总结

以上4种方式基本包含了单例模式使用的四种方法，考虑了多线程下单例模式的线程安全性和有继承情况下的注册式单例实现。
老规矩上pdf,呵呵。/Files/zhenxuanpan/设计模式之单例模式的详解.pdf

在设计模式中的创建者模式中有三中模式可以说是同根同源。它们就是简单工厂模式、工厂模式、抽象工厂模式。下面我们逐一看它们的特点以及异同。

1、简单工厂模式

简单工厂模式并不在GoF的23种设计模式之列，不过它却是工厂模式和抽象工厂模式最简化的一种表现形式。它通过一个工厂类Factory来根据传入的参数决定构建具体哪一类产品的实例。它屏蔽了客户端创建具体产品实例的过程，提供给客户端可用的对象。但是它有一个致命的缺点就是Factory中的逻辑比较负责，要根据参数去判断生成怎么样的产品实例给客户端。特别是产品实例动态的增加的时候，你必须要修改Factory的判断逻辑，这一点违背了“开-闭原则”。可能这也是它未能入选23种设计模式的原因吧。

上uml图吧，这样更易于理解（图来源于百度百科）

2、工厂模式

如果说什么模式应用最多，个人认为就是工厂模式了。例如想Spring中Factory,Bean实在是太常见了。你自己平时写程序，new一个对象也是非常常见的，所以工厂模式常见也是非常正常。如果要说工厂模式和抽象工厂模式的区别，那就要先看抽象工厂的缺点了，违背了“开-闭”原则。所以工厂模式，就作出了改进，每一个Product都有一个自己对应的工厂。当然这些工厂都继承于抽象工厂类，并实现了工厂方法。

上uml图吧，自己可以对比一下，图片来源于大话设计模式

3、抽象工厂模式

看了上面的工厂模式，你是不是会觉得很爽，因为大部分new出来的对象都可以用工厂去产生，确实，在Spring中，所有的类成员变量都是配置文件配进去的，也就是通过工厂产生的。但是你会发现一个问题，如果是一个工厂只产生一个bean，那么如果我想产生一组bean怎么办呢？因为很多时候某一组bean是捆绑在一起的。例如db中，sqlServer,mysql,oracle各自对应一组Connection, resultSet等，那是你这个时候就需要抽象工厂了，它提供了这样对一组or一类bean区分的需求的支持。

上uml图吧，偶觉得有图有真相，呵呵。图片仍旧来自大话设计模式。

4、总结

通过上面的介绍和图例，基本可以看出三种工厂模式的特点和异同。主要是它们的不同点，简单工厂封装了构建对象的过程，但内部存在判断逻辑，所以违背了“开-闭”原则。工厂模式通过对每一个product增加一个工厂去增加弥补这个缺点。但是工厂模式又不能生成同一类型的多个product，所以抽象工厂模式通过增加多个工厂方法去解决这个问题。
最后附上文档的pdf吧。呵呵，希望对设计模式初学者有用。
/Files/zhenxuanpan/设计模式之三种工厂.pdf