定義了乙個建立物件的介面，但由子類決定更要例項化的類是哪乙個。工廠方法讓類把例項化推遲到子類。
工廠方法模式能封裝具體型別的例項化。在抽象的creator中，任何其他實現的方法，都可能建立這個工廠方法所製造出來的產品，==但只有子類真正實現這個工廠方法並建立產品==。
注意：定義中「由子類決定要例項化的類是哪乙個」，所謂的「決定」，並不是指模式允許子類在執行時做決定，而是在編寫建立者時，不需要知道實際建立的產品是哪乙個。在執行時客戶選擇使用哪個子類，自然就決定了實際建立的產品是什麼。
個人理解：這個模式的優點有：
把物件的建立放在方法裡，而不是直接new，這樣除了不需要直接new物件（避免了針對實現程式設計），還能在方法裡新增了各種邏輯，能更精確的控制物件的產生。（如可以新增引數等）
建立者是乙個超類（抽象類、介面），產品也是乙個超類，在建立者類裡的用於生產產品（建立物件）工廠方法也是抽象的，而且返回值是產品；這意味著：
任何實現了建立者類的子類都必須重寫這個工廠方法，不同的子類對這個方法可以有不同的重寫，從而可以生產不同的產品。如果想生產新品種的產品，只需要建立乙個新的實現了建立者類的類然後重寫這個方法即可，原來的**完全不受影響，很正做到了ocp
返回值是抽象的產品，建立類的其他方法可以繼續用這個返回值。根據黎克特制替換原則，任何父類出現的地方子類都能出現。這就是說，子類返回的產品都能繼續被建立者類的其他方法所使用，做到了面向介面程式設計。
abstract product factorymethod(sring type)不能讓高層元件依賴於低層元件，而且，不管高層或者低層，兩者都應該依賴於抽象。
變數不可以持有具體類的引用
如果使用直接new物件，就會持有具體類的引用。可以改用工廠來避開這樣的做法。
不要讓類派生字具體類
如果派生自具體類，就會依賴這個具體類。==要派生自乙個抽象類或介面。==
不要覆蓋基類中的已經實現的方法。
如果覆蓋基類已經實現了的方法，意味著這個基類並不是乙個真正適合被繼承的抽象。==基類中已經實現了的方法，應該由子類共享==！
==提供乙個介面，用於建立相關或依賴物件的家族，而不需要明確指定具體類。==
允許客戶使用抽象的介面建立一組相關的產品，而不需要知道實際產出的具體產品室什麼。這樣依賴，客戶就從具體的產品中被解耦。
抽象工廠的任務是==定義乙個負責建立一組產品的介面==。介面內的每個方法都負責建立乙個產品。
我們利用==實現抽象工廠的子類通過對這些方法不同的重寫來生產具體的產品==。所以在抽象工廠中里利用工廠方法是實現生產方法是相當自然的做法。
工廠方法：目前還不知道將來需要例項化哪些具體類時可以使用
c 設計模式 之 工廠模式之 工廠模式
1 uml類圖 實現和依賴關係 實現 sportfactory jeepfactory hatchbackfactory 實現 ifactory 介面 sportcar jeepcar hatchbackcar 實現 icar 介面 依賴 ifactory 依賴 icar sportfactory ...
設計模式 設計模式之工廠模式
工廠方法模式 建立模式 使用場景？作用？形態？場景 大量類似的實體類 要建立的實體類都是同一本質的東西 披薩 有部分類似功能 準備 烘烤 切法 實現方式不一樣 準備的材料不同 烘烤時間不同 切法不同 將繁瑣複雜的建立類的過程聚集在一起，有序清晰 把具體例項化的過程從客戶 中抽離 作用 1 將建立物件...
設計模式 工廠模式之簡單工廠
工廠模式可以分為 簡單工廠模式 普通工廠模式 靜態工廠模式 抽象工廠模式 簡單工廠模式 就是如何去例項化物件的問題，對於很容易變化的問題，應該考慮用乙個單獨的類來做這個創造例項的過程，這個單獨的類就是工廠 例子 通過簡單工廠建立各種圖形的實現過程 簡單工廠模式建立步驟 建立乙個介面 例 圖形介面 建...