小菜學設計模式——工廠方法模式

背景

    簡單工廠模式最大的優勢在於工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態實例化相關類，對於客戶端來講，去除了與具體產品的依賴。若是，項目須要擴展，新增一種產品須要簡單工廠模式生產，那麼工廠內部必須重寫修改必要的邏輯判斷，這對於面向接口編碼是很是不肯意看到的，由於他違背了面向對象設計原則：開放封閉原則。

    那麼如何咱們才能解決這個問題呢？工廠方法模式的產生應該也是簡單工廠模式的改進。

一、使用意圖

    工廠方法模式實現時，客戶端須要決定實例化化哪個工廠方法來生產產品，換句話說，工廠方法模式就是僅僅把簡單工廠模式的內部必要邏輯判斷移到了客戶端代碼來進行，那麼，之前是修改工廠類內部的邏輯判斷，如今變成了修改客戶端的業務邏輯，說實話，相對於簡單工廠模式稍微好點，可是仍是難以擴展。

二、生活實例

    生活到處是例子，只要有簡單工廠模式的地方，天然能夠調整爲工廠方法模式。

三、Java 例子（框架、JDK 、JEE）

    仍是說之前那個報表導出的例子，工廠方法模式的話應該這樣寫，建一個超級工廠接口，IExportFactory，裏面聲明一個抽象方法，這個方法就是生產對象，估計你也知道了，生產的對象確定是全部產品的超類，那麼，若是你想要一個PdfExport實例的話，須要定義一個 PdfExportFactory 實現 IExportFactory ，同時實現裏面的方法，生產對應的PdfExport；那麼客戶端本身new 一個工廠，而後用工廠實例化對象；若是想要擴展一個產品，那麼新增一個工廠類實現IExportFactory就能夠了，呵呵，這個到底有什麼好啊！

四、模式類圖

    

五、模式優勢

    談不上什麼優勢，想一想啊，簡單工廠模式能夠改進爲靜態工廠模式，就是把生產產品的方法設爲靜態的，而工廠方法呢？不能夠，由於工廠方法模式重在方法，這個方法經過繼承動態實現完成，因此多是靜態的。固然，工廠方法模式還能夠改進爲在一個工廠內部提供不一樣的方法來生成不一樣的產品，那麼就能夠避免過多的工廠類了，雖然這樣子能夠減小類，可是實際上它和簡單工廠同樣違背了開放封閉原則，若是後期擴展一個新的產品，那麼必須在工廠內部中新增一個生產對應產品的方法。

六、與相似模式比較

    只能與簡單工廠模式比較，由於抽象工廠還沒沒有深刻學習，懂的不是不少；簡單工廠模式和工廠方法模式沒什麼可說的，感受代碼就必須在if-else中度過。