問題描述
無論工廠方法模式，或者是抽象工廠模式，客戶端程序在創建一個對象的時候，都依賴於一個具體的工廠類。本質上來說，客戶程序和這些具體的工廠類緊緊的綁死了。但是，某些程序(例如框架程序)可能無法訪問這些具體的工廠類，也可能需要一種動態的，可以配置的方式來創建對象。原型模式通過一個原型管理器來提供這種動態性，通過複製/克隆一個已經存在的對象來解除對於工廠類的依賴。
原型模式
如圖所示，Prototype定義了一個抽象的Clone()接口，任何一個類型，只要支持了這個抽象接口，客戶端都可以通過該類型的一個實例來複制/克隆出一個該類型的新的實例。
討論
設計一個原型模式的時候，需要考慮如下問題：
1）。原型管理器：用於註冊，取消註冊原型對象。客戶通過關鍵字查詢原型對象。原型管理器支持原型的動態註冊和取消註冊，爲原型模式提供了動態性和可配置性。
2）。深拷貝：在實現Clone()接口的時候，通常需要考慮深拷貝來保證原型對象和複製對象的獨立性。否則，實例對象內部的資源(例如指針，文件句柄， Socket等)在程序運行中可能出現一些經典錯誤例如：懸掛指針的訪問，指針的重複釋放等問題。
3）。克隆對象的初始化：如前所述，Clone()接口適用於任何類型，不能攜帶任何參數。因此，在實現Clone()方法的時候，需要考慮是否提供初始化函數來初始化克隆對象。Java語言根基類Object聲明瞭clone()方法如下，因此任何Java對象只要實現了clone()方法，就天然的支持了原型模式。
class Object extends Throwable
{
...
protected native Object clone() throws CloneNotSupportedException;
...
}
Clone()接口是否可以看作是一個特殊的工廠方法？如果拘泥於工廠方法模式的形式上看，原型模式當然不是工廠方法。但是從”如何通過一個穩定接口來創建實例對象”的角度看，原型模式可以是一種特殊的工廠方法模式。使用原型模式的客戶軟件依據原型管理器查找一個原型對象並調用Clone()接口來複制一個對象；使用工廠方法的客戶軟件依據一個具體工廠類並調用其提供的工廠方法來創建對象。原型模式不需要創建工廠方法類，也更加靈活可配置。原型模式甚至隱藏了所創建對象的抽象類型，因爲所有的克隆操作都是基於Prototype接口的Clone()方法來完成的。比較起來，工廠方法模式只是提供一種隱藏所創建對象的具體類型的方法，其客戶端依然需要了解所創建對象的抽象類型。從這個角度上講，原型模式在類型隱藏方面比工廠方法模式更加的抽象。