淺談原型與抽象工廠
從相似的角度來說，它們兩個都通過Composite的方式,把實例化的過程從具體使用這些對象的類中分離出去，只讓用戶知道調用Manager或Factory的哪些方法來實例化而不用記住具體的類名。抽象工廠和原型模式是基于相同原理的模式，唯一的不同之處就是實例化的過程，抽象工廠是基于new來實例化對象的（缺點是HardCode,編譯時已經決定了要實例化的具體是什么對象），而原型是基于Clone來創建對象的（優點是在程序運行時，能夠像策略模式一樣實時更換對象，創建出基于相同接口的不同對象。）我更傾向的觀點把原型模式歸為抽象工廠的一種具體實現形式，強調實例的創建時是基于另一個實例的Clone方法。
上面說了原型模式這么多好處。下面將按照《HeadFirst設計模式》的例子的改版來做一下解說。
場景：
你接了某個游戲公司的項目，項目為設計一個角色扮演游戲。在游戲中，當英雄在動態創建的場景中闖蕩的時候，免不了要與各色各樣的怪物來戰斗。不僅有游戲公司預先定制好的怪物，而且還能夠讓高級玩家手動創造新的怪物（預先定義好的怪物的特征幾乎都不一樣,行為比用戶自定義的怪物要多，用戶自定義的怪物只具備些簡單行為，跟尾隨在身后的吉祥物差不多。對于自定義的怪物，玩家能夠選擇怪物的類型，例如是Dragon還是Bird，并且為其選擇顏色等）。Monster的設計如下：
凡是Monster都要實現IMonster的接口。DuckMonster和CakeMonster為游戲公司預設的怪物類，場景中每出現一只頭種怪物，都需要用到new DuckMonster或new CakeMonster。通過下面的兩個工廠之一來解耦其實例化的代碼。
而blueEyesWhiteDragon和bedEyesBlackBird為用戶定義的一種怪物（請注意！他們不是類，而是實例），場景中每出現一頭這種怪物，都需要調一次blueEyesWhiteDragon.Clone()或bedEyesBlackBird.Clone()。
先說一下MonsterFactory1與MonsterFactory2。
MonsterFactory1的缺點：MonsterFactory1每當增加一種新怪物的時候，就要增加一個GetXXMonter方法，等于不斷地對外開放接口，而且方法多起來難以管理。
或者說為DuckMonster和CakeMonster各自建一個Factory，好處是只需要一個Get方法。缺點自然是Factory太多，無法管理。
MonsterFactory2的缺點自然是每增加一種新怪物，就多一個if來根據type參數來取得實例，不符合面向對象思想的“對擴展開放，對修改關閉”的原則。
到了MonsterPrototypeManager，通過依賴注入（對于依賴注入不理解的可以看看我的另外兩篇文章：理解Spring中的依賴注入以及利用Spring解耦VS的WebService），我們可以不用寫任何初始化的代碼，來完成實例的創建，并且注入到regMonsterList這個Dictionary類的實例中。想獲得實例，只要把type傳進去GetSpecificMonster，就能從regMonsterList中取得相應的實例，并返回Clone后的實例。
在游戲過程中，高級玩家創建了一種新的怪物。由于這種怪物是一個實例，而不是一個類，所以還可以動態添加到regMonsterList當中，需要的時候可以拿出來Clone一下，來創建新實例。而MonsterFactory們就只能在編譯時期確定好具體定義好的怪物“類”，靈活性比Prototype模式的MonsterPrototypeManager要差。
【編輯推薦】
