分工越細，項目就更容易拓展

工廠模式實現了創建者和調用者分離。
設計模式是一種思想，學習設計模式可以提高你的思考角度。

面向對象設計的基本原則：

OCP（開閉原則，Open-Closed Principle）：一個軟件的實體應當對擴展開放，對修改關閉。
DIP（依賴倒轉原則，Dependence Inversion Principle）：要針對接口編程，不要針對實現編程。
LoD（迪米特法則，Law of Demeter）：只與你直接的朋友通信，而避免和陌生人通信。類盡量少地以來其他類，實現類與類之間的解耦。利于擴展。

不使用簡單工廠的情況

簡單工廠模式

package factory;public class CarFactory {public static Car createCar(String type) {Car c = null;if ("奧迪".equals(type)) {c = new Audi();} else if ("奔馳".equals(type)) {c = new Benz();}return c;} }

方法工廠模式

工廠方法模式要點：

– 為了避免簡單工廠模式的缺點，不完全滿足OCP。
– 工廠方法模式和簡單工廠模式最大的不同在于，簡單工廠模式只有一個（對于一個項目
或者一個獨立模塊而言）工廠類，而工廠方法模式有一組實現了相同接口的工廠類。

實際項目中，還是簡單工廠用的比較多

簡單工廠模式和工廠方法模式PK:

– 結構復雜度
從這個角度比較，顯然簡單工廠模式要占優。簡單工廠模式只需一個工廠類，而工廠方法模式的工廠類隨著產品類個數增加而增加，這無疑會使類的個數越來越多，從而增加了結構的復雜程度。
– 代碼復雜度
代碼復雜度和結構復雜度是一對矛盾，既然簡單工廠模式在結構方面相對簡潔，那么它在代碼方面肯定是比工廠方法模式復雜的了。簡單工廠模式的工廠類隨著產品類的增加需要增加很多方法（或代碼），而工廠方法模式每個具體工廠類只完成單一任務，代碼簡潔。
– 客戶端編程難度
工廠方法模式雖然在工廠類結構中引入了接口從而滿足了OCP，但是在客戶端編碼中需要對工廠類進行實例化。而簡單工廠模式的工廠類是個靜態類，在客戶端無需實例化，這無疑是個吸引人的優點。
– 管理上的難度
這是個關鍵的問題。
我們先談擴展。眾所周知，工廠方法模式完全滿足OCP，即它有非常良好的擴展性。那是否就說明了簡單工廠模式就沒有擴展性呢？答案是否定的。簡單工廠模式同樣具備良好的擴展性——擴展的時候僅需要修改少量的代碼（修改工廠類的代碼）就可以滿足擴展性的要求了。盡管這沒有完全滿足OCP，但我們不需要太拘泥于設計理論，要知道，sun提供的java官方工具包中也有想到多沒有滿足OCP的例子啊。
然后我們從維護性的角度分析下。假如某個具體產品類需要進行一定的修改，很可能需要修改對應的工廠類。當同時需要修改多個產品類的時候，對工廠類的修改會變得相當麻煩（對號入座已經是個問題了）。反而簡單工廠沒有這些麻煩，當多個產品類需要修改是，簡單工廠模式仍然僅僅需要修改唯一的工廠類（無論怎樣都能改到滿足要求吧？大不了把這個類重寫）。

? 根據設計理論建議：工廠方法模式。但實際上，我們一般都用簡單工廠模式。

抽象工廠模式

– 用來生產不同產品族的全部產品。（對于增加新的產品，無能為力；
支持增加產品族）
– 抽象工廠模式是工廠方法模式的升級版本，在有多個業務品種、業務
分類時，通過抽象工廠模式產生需要的對象是一種非常好的解決方式。

---

總結

工廠模式要點：
– 簡單工廠模式(靜態工廠模式)
? 雖然某種程度不符合設計原則，但實際使用最多。
– 工廠方法模式
? 不修改已有類的前提下，通過增加新的工廠類實現擴展。
– 抽象工廠模式
? 不可以增加產品，可以增加產品族！

? 應用場景
– JDK中Calendar的getInstance方法
– JDBC中Connection對象的獲取
– Hibernate中SessionFactory創建Session
– spring中IOC容器創建管理bean對象
– XML解析時的DocumentBuilderFactory創建解析器對象
– 反射中Class對象的newInstance()
– servlet:工廠模式+單例模式

總結

以上是生活随笔為你收集整理的【Java设计模式】工厂模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。