本筆記摘抄自：https://www.cnblogs.com/PatrickLiu/p/7640873.html，記錄一下學習程序以備后續查用，
一、引言
很多人說原型設計模式會節省機器記憶體，他們說是拷貝出來的物件是原型的復制，不會使用記憶體，我認為這是不對的，因為拷貝出來的每一個物件都是實際
存在的，每個物件都有自己獨立的記憶體地址且會被GC回收，如果就淺拷貝來說，可能會公用一些欄位(參考型別)，但深拷貝是不會的，所以說原型設計模式會
提高記憶體使用率是不一定的，具體還要看當時的設計，如果拷貝出來的物件快取了，每次使用的是快取的拷貝物件，那就另當別論，再說該模式本身解決的不
是記憶體使用率的問題，
附：淺復制與深復制的區別
淺復制一個物件：
1）如果這個物件(如int age=18 )是值型別，則得到的物件是一個全新的值型別物件(新的記憶體地址)；
2）如果這個物件是參考型別(如class Person)：
I、這個物件中的值型別(如person.Age=18)是一個全新的值型別物件(新的記憶體地址)；
II、這個物件中的參考型別是公用的(同一記憶體地址)，當原始參考型別的值變化時，新生成物件的參考型別的值也會跟著變化，
深復制一個物件：
無論之前這個物件是值型別還是參考型別，得到的新物件都是一個全新的物件(新的記憶體地址)，
在軟體系統中，當創建一個類的實體的程序很昂貴或很復雜，并且我們需要創建多個這樣的類的實體時，如果用new運算子去創建時，會增加創建的復雜度
與客戶代碼的耦合度，如果采用工廠方法模式來創建這樣的實體物件的話，隨著產品類的不斷增加，導致子類的數量不斷增多，也導致了相應工廠類的增加，
系統復雜程度隨之增加，所以此時使用工廠方法模式來封裝類的創建程序并不合適，
由于每個類的實體都是相同的（這個相同指的是型別相同，但是每個實體的狀態引數會有不同，如果狀態數值也相同就沒意義了），有一個這樣的物件就可
以了，當我們需要多個相同的類實體時，可以通過對原來物件拷貝一份來完成創建，這個思路正是原型模式的實作方式，
二、原型模式介紹
原型模式：英文名稱--Prototype Pattern；分類--創建型，
2.1、動機（Motivate）
在軟體系統中，經常面臨著“某些結構復雜的物件”的創建作業，由于需求的變化，這些物件經常面臨著劇烈的變化，但是它們卻擁有比較穩定一致的介面，
如何應對這種變化？如何向“客戶程式（使用這些物件的程式）”隔離出“這些易變物件”，從而使得“依賴這些易變物件的客戶程式”不隨著需求改變而改變？
2.2、意圖（Intent）
使用原型實體指定創建物件的種類，然后通過拷貝這些原型來創建新的物件，--《設計模式》Gof
2.3、結構圖（Structure）
2.4、模式的組成
從上圖可以看出，在原型模式的結構圖有以下角色：
1）原型類（Prototype）：原型類，宣告一個Clone自身的介面，
2）具體原型類（ConcretePrototype）：實作一個Clone自身的操作，
在原型模式中，Prototype通常提供一個包含Clone方法的介面，具體的原型ConcretePrototype使用Clone方法完成物件的創建，
2.5、原型模式的具體實作
《大話西游之大圣娶親》這部電影，里面有這樣一個場景：牛魔王使用無敵牛虱大戰至尊寶，至尊寶的應對之策就是--從腦后拔下一撮猴毛，吹了口仙氣，
無數猴子猴孫現身來大戰牛魔王的無敵牛虱，至尊寶的猴子猴孫就是該原型模式的最好體現，至尊寶創建自己的一個副本，不用還要重新孕育五百年，然后出
世、再學藝，最后再來和老牛大戰，假如這樣的話，估計黃花菜都涼了，至尊寶有3根救命猴毛，輕輕一吹，想要多少個自己就有多少個，方便、快捷，
class Program { /// <summary> /// 抽象原型，定義了原型本身所具有特征和動作，該型別就是至尊寶， /// </summary> public abstract class Prototype { //戰斗--保護師傅 public abstract void Fight(); //化緣--不要餓著師傅 public abstract void BegAlms(); //吹口仙氣--變一個自己出來 public abstract Prototype Clone(); } /// <summary> /// 具體原型，例如：行者孫A，他只負責與從天界寵物下界的妖怪戰斗和化緣齋飯食， /// </summary> public sealed class MonkeyKingPrototype : Prototype { //戰斗--保護師傅 public override void Fight() { Console.WriteLine("七十二變，集萬千武藝于一身，"); } //化緣--不要餓著師傅 public override void BegAlms() { Console.WriteLine("阿彌陀佛！施主，請施舍點飯食，"); } //吹口仙氣--變一個自己出來 public override Prototype Clone() { return (MonkeyKingPrototype)MemberwiseClone(); } } /// <summary> /// 具體原型，例如：孫行者B，他只負責與自然界修煉成妖的妖怪戰斗和化緣水果， /// </summary> public sealed class NewskyPrototype : Prototype { //戰斗--保護師傅 public override void Fight() { Console.WriteLine("七十二變，集萬千武藝于一身，"); } //化緣--不要餓著師傅 public override void BegAlms() { Console.WriteLine("阿彌陀佛！施主，請施舍點水果，"); } //吹口仙氣--變一個自己出來 public override Prototype Clone() { return (NewskyPrototype)MemberwiseClone(); } } static void Main(string[] args) { #region 原型模式 Prototype monkeyKing = new MonkeyKingPrototype(); Prototype monkeyKing1 = monkeyKing.Clone(); Prototype monkeyKing2 = monkeyKing.Clone(); Prototype newsky = new NewskyPrototype(); Prototype newsky1 = newsky.Clone(); Prototype newsky2 = newsky.Clone(); //孫行者A打妖怪 monkeyKing1.Fight(); //孫行者B去化緣 newsky2.BegAlms(); Console.Read(); #endregion } }View Code
運行結果如下：
三、原型模式的實作要點
Prototype模式同樣用于隔離類物件的使用者和具體型別（易變類）之間的耦合關系，它同樣要求這些“易變類”擁有“穩定的介面”，
Prototype模式對于“如何創建易變類的物體物件”（創建型模式除了Singleton模式以外，都是用于解決創建易變類的物體物件的問題的）采用“原型克隆”的方
法來做，它使得我們可以非常靈活地動態創建“擁有某些穩定介面”的新物件——所需作業僅僅是注冊一個新類的物件（即原型），然后在任何需要的地方不斷
地Clone，
Prototype模式中的Clone方法可以利用.NET中的Object類的MemberwiseClone()方法或者序列化來實作深拷貝，
3.1、原型模式的優點
1）原型模式向客戶隱藏了創建新實體的復雜性，
2）原型模式允許動態增加或較少產品類，
3）原型模式簡化了實體的創建結構，工廠方法模式需要有一個與產品類等級結構相同的等級結構，而原型模式不需要這樣，
4）產品類不需要事先確定產品的等級結構，因為原型模式適用于任何的等級結構，
3.2、原型模式的缺點
1）每個類必須配備一個克隆方法，
2）配備克隆方法需要對類的功能進行通盤考慮，這對于全新的類不是很難，但對于已有的類不一定很容易，特別當一個類參考不支持串行化的間接物件，或
者參考含有回圈結構的時候，
3.3、原型模式的使用場景
1）資源優化場景
類初始化需要消化非常多的資源，這個資源包括資料、硬體資源等，
2）性能和安全要求的場景
通過new產生一個物件需要非常繁瑣的資料準備或訪問權限時，則可以使用原型模式，
3）一個物件多個修改者的場景
一個物件需要提供給其它物件訪問而且各個呼叫者可能都需要修改其值時，可以考慮使用原型模式拷貝多個物件供呼叫者使用，在實際專案中，原型模式很少
單獨出現，一般是和工廠方法模式一起出現，通過clone的方法創建一個物件，然后由工廠方法提供給呼叫者，
四、.NET中原型模式的實作
在.NET中，微軟已經為我們提供了原型模式的介面實作，該介面就是ICloneable，其實這個介面就是抽象原型，提供克隆方法，相當于與上面代碼中Prototype
抽象類，其中的Clone()方法實作原型模式，如果想自定義的類具有克隆的功能，首先需要在類定義時實作ICloneable介面的Clone方法，
namespace System { [ComVisible(true)] public interface ICloneable { object Clone(); } }
其實在.NET中實作了ICloneable介面的類有很多，如下圖所示（只截取了部分，可以用ILSpy反編譯工具進行查看）：
五、總結
到本篇為止，所有的創建型設計模式就寫完了，學習設計模式應該是一個循序漸進的程序，當我們寫代碼的時候不要一上來就用什么設計模式，而是通過重構
來使用設計模式，
下面總結一下創建型的設計模式：
單例模式解決的是物體物件個數的問題，除了單例模式之外，其它的創建型模式解決的都是new所帶來的耦合關系，工廠方法模式、抽象工廠模式、建造者模
式都需要一個額外的工廠類來負責實體化“易變物件”，而原型模式則是通過原型（一個特殊的工廠類把工廠和物體物件耦合在一起了）來克隆“易變物件”，如果
遇到“易變類”，起初的設計通常從工廠方法模式開始，當遇到更多的復雜變化時，再考慮重構為其他三種工廠模式（抽象工廠模式、建造者模式、原型模式），
一般來說，如果可以使用工廠方法模式，那么一定可以使用原型模式，但是原型模式的使用情況一般是在類比較容易克隆的條件之上，如果是每個類的實作都
比較簡單，只需要實作MemberwiseClone而沒有參考型別的深拷貝，那么就更加適合了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/79130.html
標籤：C#
上一篇：你們的作業電腦有監控嗎？