依賴關系的倒置

　　抽象不應該依賴于實現細節，實現細節應該依賴于抽象。-抽象A直接依賴于實現細節b（軟件易脆，很容易需要重新編譯）

　　-抽象A依賴于抽象B，實現細節b依賴于抽象B

　　動機（Motivation）

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

　　意圖（Intent）

　　使用原型實例指定創建對象的種類，然后通過拷貝這些原型來創建新的對象

　　　　　　　　　　　　　　　　　　　　　　　　——《設計模式》GoF

　　結構（Structure）

　　例說Prototype應用

　　上面的代碼，GameSystem依賴于具體的new的對象，如果面臨對象變化，例如如果要增加一個新的角色，就要重新修改編譯了。對此，我們就可以用工廠方法來改變，但是，對于每一個類型都要寫一個工廠類，比較繁瑣。我們也可以用抽象工廠方法，創建一組對象。但這里我們選擇使用原型模式。

　　先把GameSystem里用到的類型換為抽象類型。

　　再將需要new的具體對象用參數傳入，這樣在GameSystem這個客戶程序里面就只依賴于抽象而不依賴于具體了。具體的NormalActorA、FlyActorA等都不出現在GameSystem中。

　　應用程序

　　給抽象類增加Clone抽象方法

　　給具體類實現Clone方法

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

如下圖，左邊是棧，右邊是堆，（.NET的類都是在堆上）

　　如果想深拷貝，除了用笨辦法，還可以用序列化的方式來做。首先需要把類標記為可序列化，然后將類序列化到內存，再把內存中的類反序列化，反序列化得到的對象和原來的對象一定是深拷貝。

　　在對于結構中的圖，可以對應為：Client就是GameSystem，Operation方法就是Run。Prototype抽象類就對應NormalActor，ConcretePrototype即NormalActorA。

　　Prototype模式的幾個要點

　　Prototype模式同樣用于隔離類對象的使用者和具體類型（易變類）之間的耦合關系，它同樣要求這些“易變類”擁有“穩定的接口”。Prototype模式對于“如何創建易變類的實體對象”（創建型模式除了Singleton模式以外，都是用于解決創建易變類的實體對象的問題的）采用“原型克隆”的方法來做，它使得我們可以非常靈活地動態創建“擁有某些穩定接口”的新對象——所需工作僅僅是注冊一個新類的對象（即原型），然后在任何需要的地方不斷地Clone。

　　Prototype模式中的Clone方法可以利用.NET中的Object類的MemberwiseClone()方法或者序列化來實現深拷貝。

　　有關創建型模式的討論

　　Singleton模式解決的是實體對象個數的問題。除了Singleton之外，其他創建型模式解決的都是new所帶來的耦合關系。

　　Factory Method，Abstract Factory，Builder都需要一個額外的工廠類來負責實例化“易變對象”，而Prototype則是通過原型（一個特殊的工廠類）來克隆“易變對象”。（其實原型就是一個特殊的工廠類，它只是把工廠和實體對象耦合在一起了）如果遇到“易變類”，起初的設計通常從Factory Method開始，當遇到更多的復雜變化時，再考慮重構為其他三種工廠模式（Abstract Factory，Builder，Prototype）。

　　一般來說，如果可以使用Factory Method，那么一定可以使用Prototype。但是Prototype的使用情況一般是在類比較容易克隆的條件之上，如果是每個類實現比較簡單，都可以只用實現MemberwiseClone，沒有引用類型的深拷貝，那么就更適合了。Prototype如果要實現深拷貝，還需要在每個要克隆的類上加序列化標簽，這點復雜度要考慮進程序中。

it知識庫：C#面向對象設計模式縱橫談：Prototype 原型模式，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。