一.定义
原型模式(Prototype Pattern)的简单程度仅次于单例模式和迭代器模式。正是由于简单，使用的场景才非常地多，其定义如下:
Specify the kinds of objects to create using a prototypical instance, and create new objects by copyingthis prototype.(用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。)
实际的类图模板如下:
原型模式的通用源码如下:
实现一个接口，然后重写clone方法，就完成了原型模式!
二.例子
用一个个性化服务账单,来说明什么是原型模式,看一则小故事.
现在电子账单越来越流行了，比如你的信用卡，每到月初的时候银行就会发–份电子邮件给你，说你这个月消费了多少，什么时候消费的，积分是多少等，这是每个月发一次。还有一种也是银行发的邮件你肯定非常有印象:广告信，现在各大银行的信用卡部门都在拉拢客户，电子邮件是一种廉价、快捷的通信方式，你用纸质的广告信那个费用多高呀，比如我行今天推出一个信用卡刷卡抽奖活动，通过电子账单系统可以一个晚上发送给600万客户，为什么要用电子账单系统呢?直接找个发垃圾邮件的工具不就解决问题了吗?是个好主意，但是这个方案在金融行业是行不通的，为什么?因为银行发送该类邮件是有要求的:
- 个性化服务
一般银行都要求个性化服务，发过去的邮件上总有一些个人信息吧，比如“XX先生”，“XX女士”等。 - 递送成功率
邮件的递送成功率有一定的要求，由于大批量地发送邮件会被接收方邮件服务器误认是垃圾邮件，因此在邮件头要增加一些伪造数据，以规避被反垃圾邮件引擎误认为是垃圾邮件。
从这两方面考虑广告信的发送也是电子账单系统（电子账单系统一般包括:账单分析、账单生成器、广告信管理、发送队列管理、发送机、退信处理、报表管理等)的一个子功能，我们今天就来考虑一下广告信这个模块是怎么开发的。那既然是广告信，肯定需要一个模版，然后再从数据库中把客户的信息一个一个地取出，放到模板中生成一份完整的邮件，然后扔给发送机进行发送处理，类图如图所示
广告模板代码
邮件类代码
Mail类就是一个业务对象，虽然比较长，还是比较简单的。我们再来看业务场景类是如何对邮件继续处理的，代码如下:
由于是随机数，每次运行都有所差异，不管怎么样，我们这个电子账单发送程序是编写出来了，也能正常发送。我们再来仔细地想想，这个程序是否有问题?Look here，这是一个线程在运行，也就是你发送的是单线程的，那按照一封邮件发出去需要0.02秒（够小了，你还要到数据库中取数据呢)，600万封邮件需要33个小时，也就是一个整天都发送不完，今天的不发送完，明天的账单又产生了，日积月累，激起甲方人员一堆抱怨，那怎么办?
好办，把sendMail修改为多线程，但是只把sendMail修改为多线程还是有问题的呀，产生第一封邮件对象，放到线程1中运行，还没有发送出去，线程2也启动了，直接就把邮件对象mail的收件人地址和称谓修改掉了，线程不安全了。说到这里，你会说这有N多种解决办法，其中一种是使用一种新型模式来解决这个问题:通过对象的复制功能来解决这个问题，类图稍作修改，如图所示
修改后的邮件类
修改后的场景类
运行结果不变，一样完成了电子广告信的发送功能，而且sendMail即使是多线程也没有关系。注意，看Client类中的粗体字mail.clone()这个方法，把对象复制一份，产生一个新的对象，和原有对象一样，然后再修改细节的数据，如设置称谓、设置收件人地址等。这种不通过new关键字来产生一个对象，而是通过对象复制来实现的模式就叫做原型模式。
三.结论
优点
- 性能优良
原型模式是在内存二进制流的拷贝，要比直接new一个对象性能好很多，特别是要在一个循环体内产生大量的对象时，原型模式可以更好地体现其优点。 - 逃避构造函数的约束
这既是它的优点也是缺点，直接在内存中拷贝，构造函数是不会执行的,优点就是减少了约束，缺点也是减少了约束，需要大家在实际应用时考虑。
使用场景
- 资源优化场景
类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。 - 性能和安全要求的场景
通过new产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 - 一个对象多个修改者的场景
一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。
在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过clone的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与Java融为一体，大家可以随手拿来使用。
