設計模式-建立型-工廠模式（FACTORY METHOD）

　　根據gof的設想，工廠方法模式被定義成了推遲實例化到子類的一種手段。「定義一個用於建立對象的接口，讓子類決定實例化哪個類。Factory Method使一個類的實例化延遲到其子類」。

　　如下是對工廠模式的結構解析。

　　

 

　　正如從圖裏能讀到的，工廠模式的初始願意並無規定一個特殊的抽象方法Create或者相似方法。工程模式的關鍵點在於延遲對象的實例化。這樣作乍看起來徹底是沒有必要的，由於這樣作的最直觀的影響就是增長了類的個數。咱們能預料獲得的結果就是，當咱們須要獲取一個新的類型的對象時，要作的第一件事就是新增長一個product類的子類和一個creator類的子類，將本來只須要直接實例化product子類就能達到目的的實現變成了須要新增長一個子creator類並推遲到了它的成員函數來實現。可是須要注意的是，全部讓軟件結構更易維護更易拓展的策略都是須要代價的。很明顯這裏的代價就是可能無限制增長的product和creator。

　　就筆者的理解來講，工廠方法模式的優點在於。

　　1. 爲客戶獲取product類對象提供了一個新的抽象，這個抽象的名字叫creator。

　　　　這裏的客戶能夠是一個類能夠是一個方法，視狀況而定。提供一個新的抽象方法的好處是顯而易見的，最直觀的就是提供了一個可被重載的新類。這個新類的做用相似於hook函數，只不過它繼承了面嚮對象語言的優勢，靈活性與可拓展性。對於客戶來講，須要打交道的再也不是product，而是creator。如書上的這個例子所描述的那樣（以下圖）。這裏的Application類就是creator，MyApplication類就是concreteCreator, Document就是product，MyDocument就是concreteProduct。能夠看到在Application類（creator）中新增了一個成員數據結構docs，用來專門收集全部通過application實例化的對象，這樣的操做能夠有不少種，根據的實際需求而定，實現的地方也能夠是在creator的父類也能夠延遲到子類。無論怎樣，這類的業務邏輯均可以被封裝到creator中，而不用暴露給客戶。對於的這類的需求都被封裝到了creator，而creator可變的理由就只有一個，關於業務邏輯的需求（單一職責原則）。比起把這些業務邏輯交給客戶來作，咱們說軟件的可維護性變高了。

　　　　值得一提的是這類業務邏輯的封裝偏偏是生成器模式（BUILDER）想達到的，不過這兩個模式各有各的側重點，生成器模式（BUILDER）強調的是生成product對象的策略，而工程模式（FACTORY METHOD）在這裏強調的是一個新的抽象，這個新的抽象能夠有不一樣的實現。稍後咱們將會講解生成器模式（BUILDER）的做用。

　　　　

　　2. 提供了一個新的類層次。

　　　　正如書上所列舉的第二個例子來講（以下圖），Figure把一部分關於它的操做委託給了Manipulator類，這裏的Figure類是creator，用戶經過獲取Figure類獲取到其對應的Manipulator對象，既是對應的product對象。這樣客戶獲取了一個很是容易理解的結構，對於一個特定的figure子類的對象，老是能夠經過方法CreateManipulator獲取到對應的Manipulator。要是你理解了這個設計的優點，是否是會頓悟原來工程模式（FACTORY METHOD）的用處是如此普遍，不少地方咱們都不自覺的在使用的這個設計模式。只是咱們沒來得及概括總結而已。這樣的設計好處是顯而易見的，更容易被人理解，同時它也遵循了開閉原則。你的設計在不知不覺間變得更優雅了。

　　　　

 　　接下來咱們討論一下一個被稱爲簡單工廠模式的實現，所謂的簡單工廠模式就是隻有creator再也不是一個抽象類，而是一個能被實例化的具體類。在實現中會往Create中加入參數，根據數據的不一樣來生成不一樣的product對象。相似於下圖。這個技巧是出如今gof的書中，同時它也是簡單工程模式的組成部分，關於簡單工程模式的詳細信息讀者能夠本身百度，這裏再也不贅述。咱們只談這個簡單工廠模式與gof書中提到的工廠模式（FACTORY METHOD）的異同點。

　　a. 簡單工廠模式只是在形式上與工廠模式相似。

　　　　若是讀者理解了上面關於工廠模式的解讀，便會發現，gof描述的工廠模式強調的推遲對象的實例化到其子類，若是creator子類這個概念已經不存在了，彷佛在生拉硬拽的讓這兩個模式的扯上關係有點太牽強了。能夠說簡單工廠模式借鑑了工廠模式的某些概念（如： creator）以及某些技巧（如：參數化建立），可是工廠模式的核心理念它並無符合（推遲對象的實例化）。 

　　b. 簡單工廠模式能夠很好符合數據驅動型設計。

　　　　做爲一個新晉設計模式，簡單工廠模式也不是徹底不可取的。咱們考慮一種狀況，若是設計中creator徹底沒有必要拓展，這個時候咱們還會考慮新生成一個creator父類嗎？同時簡單工廠模式是能夠經過輸入參數來決定建立類型的，全部它對於那種數據驅動設計師很是合適的，經過不一樣的輸入來決定相應的對象。