一、動機（Motivation）

在軟件系統(tǒng)中，經常面臨著“某些結構復雜的對象”的創(chuàng)建工作；由于需求的變化，這些對象經常面臨著劇烈的變化，但是它們卻擁有比較穩(wěn)定一致的接口。
如何應對這種變化？如何向“客戶程序（使用這些對象的程序）”隔離出“這些易變對象”，從而使得“依賴這些易變對象的客戶程序”不隨著需求改變而改變？

二、意圖（Intent）

使用原型實例指定創(chuàng)建對象的種類，然后通過拷貝這些原型來創(chuàng)建新的對象——《設計模式》GoF

三、結構（Structure）

我們看了這么多設計模式的類圖了，大家應該也總結出一些經驗來，客戶端依賴的都是抽象的接口，【這個接口不是C#語言里面的Interface或者抽象類】，原型模式里面有一個抽象原型對象，他是穩(wěn)定的，通過自身的克隆實現(xiàn)對象的創(chuàng)建。

四、模式的組成

可以看出，在原型模式的結構圖有以下角色：
（1）、原型類（Prototype）：原型類，聲明一個Clone自身的接口；
（2）、具體原型類（ConcretePrototype）：實現(xiàn)一個Clone自身的操作。
在原型模式中，Prototype通常提供一個包含Clone方法的接口，具體的原型ConcretePrototype使用Clone方法完成對象的創(chuàng)建。

五、 原型模式的具體實現(xiàn)

假設在一些打斗游戲場景中，有這樣一些角色，普通(NormalActor),可以飛的(FlyActor).

//抽象原型（相當于工廠）
public abstract class NormalActor
{
    public abstract NormalActor Clone();
}

public abstract class FlyActor
{
    public abstract FlyActor Clone();
}

//具體實現(xiàn)
public class NormalActorA : NormalActor
{
    public override NormalActor Clone()
    {
        return (NormalActor)this.MemberwiseClone();
    }
}

public class FlyActorA : FlyActor
{
    public override FlyActor Clone()
    {
        return (FlyActor)this.MemberwiseClone();
    }
}

客戶程序：

public class GameSystem
{
    public void Run(NormalActor normalActor, FlyActor flyactor)//如果把參數(shù)定義成屬性也可以的不影響設計模式的實現(xiàn)。
    {
        //需要3個小兵
        NormalActor noramlActor1 = normalActor.Clone();//克隆
        NormalActor noramlActor2 = normalActor.Clone();
        NormalActor noramlActor3 = normalActor.Clone();
        //需要兩個飛人
        FlyActor flyActor1 = flyactor.Clone();
        FlyActor flyActor2 = flyactor.Clone();
    }
}

應用程序：

internal class App
{
    public static void Main()
    {
        GameSystem gamesystem = new GameSystem();
        gamesystem.Run(new NormalActorA(), new FlyActorA(), new FlyActorA());
    }
}

有一點要注意，MemberwiseClone方法只是一種淺拷貝，它只能拷貝所有的值類型和String，如果是引用類型（例如數(shù)組），它就會只拷貝引用，而不會重新創(chuàng)建對象，例如對數(shù)組，就只會拷貝數(shù)組的地址。

六、原型模式的實現(xiàn)要點：

Prototype模式同樣用于隔離類對象的使用者和具體類型（易變類）之間的耦合關系，它同樣要求這些“易變類”擁有“穩(wěn)定的接口”。
Prototype模式對于“如何創(chuàng)建易變類的實體對象”（創(chuàng)建型模式除了Singleton模式以外，都是用于解決創(chuàng)建易變類的實體對象的問題的）采用“原型克隆”的方法來做，它使得我們可以非常靈活地動態(tài)創(chuàng)建“擁有某些穩(wěn)定接口”的新對象——所需工作僅僅是注冊一個新類的對象（即原型），然后在任何需要的地方不斷地Clone。
Prototype模式中的Clone方法可以利用.NET中的Object類的MemberwiseClone()方法或者序列化來實現(xiàn)深拷貝。

1、原型模式的優(yōu)點：

（1）、原型模式向客戶隱藏了創(chuàng)建新實例的復雜性
（2）、原型模式允許動態(tài)增加或較少產品類。
（3）、原型模式簡化了實例的創(chuàng)建結構，工廠方法模式需要有一個與產品類等級結構相同的等級結構，而原型模式不需要這樣。
（4）、產品類不需要事先確定產品的等級結構，因為原型模式適用于任何的等級結構

2、原型模式的缺點：

（1）、每個類必須配備一個克隆方法
（2）、配備克隆方法需要對類的功能進行通盤考慮，這對于全新的類不是很難，但對于已有的類不一定很容易，特別當一個類引用不支持串行化的間接對象，或者引用含有循環(huán)結構的時候。

3、原型模式使用的場景：

（1）、資源優(yōu)化場景
　　類初始化需要消化非常多的資源，這個資源包括數(shù)據(jù)、硬件資源等。
（2）、性能和安全要求的場景
　　通過new產生一個對象需要非常繁瑣的數(shù)據(jù)準備或訪問權限，則可以使用原型模式。
（3）、一個對象多個修改者的場景
　　一個對象需要提供給其他對象訪問，而且各個調用者可能都需要修改其值時，可以考慮使用原型模式拷貝多個對象供調用者使用。
在實際項目中，原型模式很少單獨出現(xiàn)，一般是和工廠方法模式一起出現(xiàn)，通過clone的方法創(chuàng)建一個對象，然后由工廠方法提供給調用者。

七、.NET 中原型模式的實現(xiàn)

在.NET中，微軟已經為我們提供了原型模式的接口實現(xiàn)，該接口就是ICloneable，其實這個接口就是抽象原型，提供克隆方法，相當于與上面代碼中Prototype抽象類，其中的Clone()方法來實現(xiàn)原型模式，如果我們想我們自定義的類具有克隆的功能，首先定義類實現(xiàn)ICloneable接口的Clone方法。其實在.NET中實現(xiàn)了ICloneable接口的類有很多。

八、創(chuàng)建型模式的總結

Singleton模式解決的是實體對象個數(shù)的問題。除了Singleton之外，其他創(chuàng)建型模式解決的都是new所帶來的耦合關系。
Factory Method，Abstract Factory，Builder都需要一個額外的工廠類來負責實例化“易變對象”，而Prototype則是通過原型（一個特殊的工廠類）來克隆“易變對象”。（其實原型就是一個特殊的工廠類，它只是把工廠和實體對象耦合在一起了）
如果遇到“易變類”，起初的設計通常從Factory Method開始，當遇到更多的復雜變化時，再考慮重構為其他三種工廠模式（Abstract Factory，Builder，Prototype）。
一般來說，如果可以使用Factory Method，那么一定可以使用Prototype。但是Prototype的使用情況一般是在類比較容易克隆的條件之上，如果是每個類實現(xiàn)比較簡單，都可以只用實現(xiàn)MemberwiseClone，沒有引用類型的深拷貝，那么就更適合了。Prototype如果要實現(xiàn)深拷貝，還需要在每個要克隆的類上加序列化標簽，這點復雜度要考慮進程序中。

到此這篇關于.Net設計模式之原型模式（Prototype）的文章就介紹到這了。希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論