原型模式

的编辑器不好用，部分内容只能截图发表了。

image.png

image.png

新建一个人员类，并声明姓名、性别、年龄等属性。

image.png

image.png

这样就实现了对象的复制，对象p2与对象p1具有完全相同的属性——你也许认为：对象的复制既然如此简单，为什么还需要使用clone方法呢？

image.png

image.png

我们发现：当改变了p2的name值之后，p1的值也跟着发生了改变。现在p1的name已经不是Caesar，和p2对象一样，它们的name都是Alexander。这是为什么呢？实际上这种赋值操作并没有真正在内存中创建一个新的的对象，Person p2 = p1;实际上是把p1的引用赋给了p2，它们指向的是堆内存中同一块内存地址。因此p1和p2的操纵的都是同一个对象。

image.png

image.png

用==操作符判断p1与p2是否同一个对象，结果为true。
下面我们使用简单的原型模式来改造Person类，使其能够完成真正意义上的对象克隆

image.png

image.png

image.png

测试后，我们发现通过p1的clone方法复制了一个一模一样的p2对象。现在我们用==操作符，看下这两个对象的内存地址是否相同：

image.png

输出结果为false。现在我们已经完全确定p1和p2并非同一个内存对象了。
这里涉及了两个概念：浅克隆与深克隆。以上的clone方式是浅克隆，接下来我们演示一下深克隆的demo。

image.png

在人员类中声明一个Address实例。

image.png

创建一个Address对象，并把地址名称设为“北京”，将该address对象赋值给Person类。
利用原型对象的克隆方法得到p2对象；接下来我们改变了address的地址为“南京”，然后我们发现p1和p2的地址都发生了改变。

image.png

用==操作符比较发现，p1和p2的address是同一个对象。这就是浅克隆，如果原型对象的成员变量为引用类型，那么仅会把成员变量的引用复制一份，给克隆对象，并没有真正的开辟一块内存空间。
正如我们所看到的，浅克隆不会真正的复制引用类型的对象，而只是复制一份对象的引用。但是这里我们我们会发现一个问题：String同样也是引用类型，为什么在浅克隆的时候，我们改变p2的name属性时，p1的name属性没有发生改变呢？很明显，在浅克隆时，String对象并非仅仅复制了引用，而是真实的在堆内存中创建了两个不同的对象——之前遗漏了对这一结果的测试，现在补上：

image.png

通过上面的结果我们可以看到：p2的name发生改变后，p1的name并没有发生改变。也就是说，通过clone我们得到了两个不同的string对象！
其实这里本来不想对这一结果进行过多的解释，但是绕过去不谈总有些说不过去，因此这里简短的谈一下String类的特殊性。以后会在写一片博客，对String类有一个详细的分析。
这里其实涉及到String常量池的概念，当使用String str = "abc";赋值时，实际上是在常量池创建了一个对象（也可能不会创建对象，如果常量池中已经存在的话）。而常量池中的对象其实是不可更改的，因此，在调用p2的setName方法时，实际上是创建了一个新的字符串对象。介绍完这些，我们再去看一下深克隆模式：

image.png

image.png

在上面的例子中，我们使Address类也实现了Cloneable接口，并且重写了clone方法。
修改Person类的clone方法，然后调用address的clone方法，将得到的address对象赋给当前address成员变量。

image.png

经过深克隆之后，我们再用==操作符比较p1的address和p2的address，发现结果为false，证明Person类的引用类型的对象真正被克隆了。
由于clone方法时一个native方法，因此它在提供便利的同时，原型模式复制对象的性能也是最快的。

image.png