目錄
- 定義
- 使用場景
- UML類圖
- 簡單實現(xiàn)
- 使用Cloneable接口
- 不實現(xiàn)Cloneable接口
- 問題
- 深拷貝-淺拷貝
- Android源碼中的原型模式
- 總結(jié)
- 優(yōu)點(diǎn)
- 缺點(diǎn)
博客地址
原型模式也是一種創(chuàng)建型設(shè)計模式,從名字就能理解,這個模式應(yīng)該有一個樣板實例,也就是原型,然后用戶從這個原型中復(fù)制出一個內(nèi)部屬性一致的實例,也就是克隆。
有時,一個對象的構(gòu)造比較復(fù)雜并且比較耗時時,直接從已有對象復(fù)制一個實例比重新構(gòu)造出來更高效。
定義
用原型實例指定創(chuàng)建對象的種類,并通過拷貝這些原型創(chuàng)建新的對象。
使用場景
- 對象的初始化要消耗非常多的資源,包括硬件,數(shù)據(jù)等??梢允褂迷湍J奖苊膺@種資源的消耗。
- 用new來實例化一個對象時需要非常繁瑣的數(shù)據(jù)準(zhǔn)備或訪問權(quán)限時,可以使用原型模式。
- 一個對象要供其他對象訪問,而每個調(diào)用者都可能會修改他的值,這時可以考慮用原型模式拷貝多個原型的對象供各個調(diào)用者使用,不互相影響,即保護(hù)性拷貝。
- 需要頻繁的創(chuàng)建相似的對象時,比如在一個循環(huán)中創(chuàng)建對象。
這里說明一下,使用clone產(chǎn)生實例并不一定都比new來的快,當(dāng)一些對象的構(gòu)造非常簡單時,new是比clone還快的。但是當(dāng)對象的構(gòu)造復(fù)雜起來的時候用new構(gòu)造就會造成較大的成本,這時clone才能體現(xiàn)出效率的優(yōu)勢。
UML類圖

其中Prototype不一定非要實現(xiàn)Cloneable接口,在演示的時候會有兩種。
簡單實現(xiàn)
使用Cloneable接口
原型,實現(xiàn)Cloneable接口:
public class Prototype implements Cloneable{
}
原型的實現(xiàn):
public class ConcretePrototype extends Prototype {
public String name;
public ArrayList<String> list = new ArrayList<>();
public ConcretePrototype() {
System.out.println("執(zhí)行了ConcretePrototype構(gòu)造函數(shù)");
}
@Override
public ConcretePrototype clone() {
ConcretePrototype prototype = null;
try {
prototype = (ConcretePrototype) super.clone();
} catch (CloneNotSupportedException e) {
e.printStackTrace();
}
return prototype;
}
@Override
public String toString() {
return "ConcretePrototype{" +
"name='" + name + '\'' +
", list=" + list +
'}';
}
}
使用:
public class MainM {
public static void main(String[] args) {
ConcretePrototype concretePrototype = new ConcretePrototype();
concretePrototype.name="yuanxing";
concretePrototype.list.add("yuanxing1");
concretePrototype.list.add("yuanxing2");
concretePrototype.list.add("yuanxing3");
ConcretePrototype cloneConcretePrototype = (ConcretePrototype) concretePrototype.clone();
cloneConcretePrototype.name = "clone";
System.out.println(concretePrototype.toString());
System.out.println(cloneConcretePrototype.toString());
}
}
輸出:

通過clone方法獲得一個實例,而且修改這個實例的內(nèi)容并不會影響原來的實例的內(nèi)容。
當(dāng)然,這樣也只是對基本數(shù)據(jù)類型有效。
不實現(xiàn)Cloneable接口
原型:
public class Prototype1 {
}
原型的實現(xiàn):
public class ConcretePrototype1 extends Prototype1 {
public String name;
public ArrayList<String> list = new ArrayList<>();
public ConcretePrototype1() {
System.out.println("執(zhí)行了ConcretePrototype構(gòu)造函數(shù)");
}
public ConcretePrototype1 clone() {
ConcretePrototype1 prototype1 = new ConcretePrototype1() ;
prototype1.name = this.name;
prototype1.list=this.list;
return prototype1;
}
@Override
public String toString() {
return "ConcretePrototype1{" +
"name='" + name + '\'' +
", list=" + list +
'}';
}
}
使用:
public class MainM {
public static void main(String[] args) {
ConcretePrototype1 concretePrototype1 = new ConcretePrototype1();
concretePrototype1.name="yuanxing";
concretePrototype1.list.add("yuanxing1");
concretePrototype1.list.add("yuanxing2");
concretePrototype1.list.add("yuanxing3");
ConcretePrototype1 cloneconcretePrototype1 = (ConcretePrototype1) concretePrototype1.clone();
cloneconcretePrototype1.name="clone";
System.out.println(concretePrototype1.toString());
System.out.println(cloneconcretePrototype1.toString());
}
}
輸出的結(jié)果是有點(diǎn)不一樣的:

直接調(diào)用Cloneable的方法是不會再次調(diào)用構(gòu)造方法的,而自己new是一定會調(diào)用構(gòu)造方法的。
我個人覺得這個應(yīng)該是偽克隆吧,只是寫了一個clone的方法,然后在方法中new出一個對象,然后要手動把自己本來的值賦值給新的對象。
問題
上面兩個都測試了name這個屬性,如果在克隆的對象里修改了ArrayList對象list會怎樣呢?來試試:
使用:
public class MainM {
public static void main(String[] args) {
ConcretePrototype concretePrototype = new ConcretePrototype();
concretePrototype.name="yuanxing";
concretePrototype.list.add("yuanxing1");
concretePrototype.list.add("yuanxing2");
concretePrototype.list.add("yuanxing3");
ConcretePrototype cloneConcretePrototype = (ConcretePrototype) concretePrototype.clone();
cloneConcretePrototype.name = "clone";
cloneConcretePrototype.list.add("clone1");
System.out.println(concretePrototype.toString());
System.out.println(cloneConcretePrototype.toString());
}
}
發(fā)現(xiàn)輸出并不是預(yù)期的:

修改了克隆出來的對象的list,原型中的list的值也變了。
深拷貝-淺拷貝
之所以會出現(xiàn)上面的情況,是因為上面的原型中使用的是淺拷貝。Cloneable的方法clone默認(rèn)就是淺拷貝,淺拷貝并不是把所有字段都重新構(gòu)造了一份,而是引用了原型中的字段。對于值類型,也就是基本數(shù)據(jù)類型來說,還有String類型,clone方法會進(jìn)行一個拷貝,可以讓拷貝的對象和原型互不干擾。但是對于引用類型(對象,集合,數(shù)組等)來說,clone方法只是讓他們指向了同一個內(nèi)存地址,所以修改其中一個的內(nèi)容,兩個都會變化。
所以對于不是基本類型的屬性,在clone的時候要手動調(diào)用引用對象的clone方法進(jìn)行拷貝,也就是深拷貝。
把重寫的clone方法加上深拷貝
@Override
public ConcretePrototype clone() {
ConcretePrototype prototype = null;
try {
prototype = (ConcretePrototype) super.clone();
prototype.list = (ArrayList<String>) this.list.clone();
} catch (CloneNotSupportedException e) {
e.printStackTrace();
}
return prototype;
}
然后就會得到我們期望的輸出:

Android源碼中的原型模式:
原型模式可能很少單獨(dú)使用吧,在書中的例子舉了個Intent,雖然實現(xiàn)了Cloneable接口,但在clone方法中是直接new的一個Intent,把原型傳進(jìn)去,然后復(fù)制給新的Intent:
package android.content;
public class Intent implements Parcelable, Cloneable {
/**
* 拷貝構(gòu)造函數(shù)
*/
public Intent(Intent o) {
this.mAction = o.mAction;
this.mData = o.mData;
this.mType = o.mType;
this.mPackage = o.mPackage;
this.mComponent = o.mComponent;
this.mFlags = o.mFlags;
this.mContentUserHint = o.mContentUserHint;
if (o.mCategories != null) {
this.mCategories = new ArraySet<String>(o.mCategories);
}
if (o.mExtras != null) {
this.mExtras = new Bundle(o.mExtras);
}
if (o.mSourceBounds != null) {
this.mSourceBounds = new Rect(o.mSourceBounds);
}
if (o.mSelector != null) {
this.mSelector = new Intent(o.mSelector);
}
if (o.mClipData != null) {
this.mClipData = new ClipData(o.mClipData);
}
}
@Override
public Object clone() {
return new Intent(this);
}
}
這里可能考慮的就是直接new比clone快吧。。
總結(jié)
原型模式主要就是拷貝對象,拷貝對象一般有兩個作用
- 保護(hù)原型不被修改,只給外部提供一個拷貝以供訪問,保護(hù)性拷貝。
- 避免構(gòu)造復(fù)雜的對象時的資源消耗問題,提升創(chuàng)建對象的效率。
優(yōu)點(diǎn)
- Object的clone方法是一個本地方法,直接操作的是二進(jìn)制流,性能會好很多。
缺點(diǎn)
- 構(gòu)造方法在clone的時候不會執(zhí)行,既是優(yōu)點(diǎn)也是缺點(diǎn),使用時要注意這個潛在的問題。