要說23種設計模式中，工廠模式無疑是最簡單的設計模式之一。雖然工廠模式簡單，基本上剛入門的新手都能看得懂，但是能用好也是不簡單的，或者說是能夠結合業務在實際的項目中使用是非常不易的，因為在實際的開發中，可以使用工廠模式的地方很容易被“if……else……”代替，而不是用工廠模式來消除“if……else……”。舉個例子——

假如有一個自動生産飲料果汁的售貨機，會根據客戶輸入的果汁類型來生産果汁給客戶的場景，相信大部分人的代碼都如下（其中FruitJuice是果汁的父類，這裡分别實現了蘋果汁AppleJuice、檸檬汁LemonJuice以及菠蘿汁PineappleJuice）

輸入“LemonJuice”

這樣實現是一點問題都沒有的，輸入“LemonJuice”然後就能得到檸檬汁，完成能夠滿足當前的需求；

但是如果我們再對未來業務的考慮，這樣實現真的好嗎？

事實上這樣的實現是不好的實現，雖然能夠完成功能需求。這裡簡單指出其實現不足，一是，如果其他類似的場景也是需要生産果汁，但是果汁的種類跟這邊的場景不一樣，無法重構成一個方法，是不是每次進行實例化前再一次這樣“if……else…… ”去判斷再實例化對應的實現類；二是從業務角度來說，果汁種類很多，未來要添加新的果汁類型的話，需要再次在業務的代碼中添加“if……else……”，如果項目中類似要創建對應果汁類型的代碼有多個地方，那必須修改多個地方，不利于維護和擴展。

那我們應該如何優化？

首先我們創建一個類FruitJuiceFactory，專門用來生産果汁的，所有的果汁生産都經過此類的方法來獲得

最後業務代碼改造成如下：

然後我們對比一下改造前後的差别：

可以看出改造後的代碼簡潔了不少，但有人可能有疑問，這不是把創建“果汁”對象的“if……else……”代碼遷移到FruitJuiceFactory裡面去了，代碼量和“if……else……”還是沒有減少，還多創建了一個工廠類，這樣真的有必要嗎？

答案是：真的有必要！

首先，如果是在實際的項目中，類似使用“果汁”對象的代碼有可能不止這一處，如果我們将生産果汁對象的方法都集中到工廠類中，封裝統一使用工廠類來創建管理，這樣才符合我們的設計原則，就不用類似再開一個新的果汁飲料實體店，然後再“if……else……”再去判斷實現一遍，如果這樣代碼冗餘很多，很不利于維護。

其次，軟件開發有一個亘古不變的真理，那就是change(變化)，不管一個軟件設計得有多好，總需要成長和改變的，否則，軟件就會“死亡”！因此，一個軟件好的設計原則是，找出軟件中可以能需要變化的部分，将它們封裝獨立出來，不要和那些不需要變化的代碼混在一起。在上述的例子中，從業務發展來說，我們明顯能夠了解到果汁的實現類會有變化，有可能實現類越來越多，比如加入葡萄汁、橙汁等，這個時候我們隻需要在變化的工廠類中添加新的實現就好，而不用在一些不需要變動的業務代碼去進行改動，而這裡的較大可能變化就是果汁實現類，不變的是業務邏輯，所以把果汁對象的創建過程封裝起來是一個較好的設計實現。

工廠模式簡大部分的應用場景跟上述例子類似，就是傳入一個具有識别性的參數，然後産生對應的實現類對象，在實際開發中可能會有一些變種，但核心的思想就是通過一個統一的類方法去管理某類型下對象的創建，實現軟件中的“變化”和“不變”高内聚低耦合。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!