工廠模式的作用，為什麽要用工廠模式？

阿新 • • 發佈：2019-04-29

了解類的構造函數原則類的調用工廠類發現自己的方法會有

工廠模式的實現方式和原理都不難理解和掌握。但是，在學習完之後，發現網上給的例子，根本體現不了工廠模式的作用。先不說存在有的例子本身就是錯誤的，主要是例子中的代碼太簡單，可以說沒必要用工廠模式，只不過是為了說明實現方式和原理。所以，會產生一種錯覺：還不如直接new 一個對象來的方便，有效。

的確，設計模式本身就有其適用的場景，並不是濫用的，否則還不如不用。

現在，我記錄一下在翻閱一些資料後，自己的理解。

首先，工廠模式是為了解耦：把對象的創建和使用的過程分開。就是Class A 想調用 Class B ，那麽A只是調用B的方法，而至於B的實例化，就交給工廠類。

其次，工廠模式可以降低代碼重復。如果創建對象B的過程都很復雜，需要一定的代碼量，而且很多地方都要用到，那麽就會有很多的重復代碼。我們可以這些創建對象B的代碼放到工廠裏統一管理。既減少了重復代碼，也方便以後對B的創建過程的修改維護。（當然，我個人覺得也可以把這些創建過程的代碼放到類的構造函數裏，同樣可以降低重復率，而且構造函數本身的作用也是初始化對象。不過，這樣也會導致構造函數過於復雜，做的事太多，不符合java 的設計原則。）

由於創建過程都由工廠統一管理，所以發生業務邏輯變化，不需要找到所有需要創建B的地方去逐個修正，只需要在工廠裏修改即可，降低維護成本。同理，想把所有調用B的地方改成B的子類B1，只需要在對應生產B的工廠中或者工廠的方法中修改其生產的對象為B1即可，而不需要找到所有的new B（）改為new B1()。

另外，因為工廠管理了對象的創建邏輯，使用者並不需要知道具體的創建過程，只管使用即可，減少了使用者因為創建邏輯導致的錯誤。

舉個例子：

一個數據庫工廠：可以返回一個數據庫實例，可以是mysql，oracle等。

這個工廠就可以把數據庫連接需要的用戶名，地址，密碼等封裝好，直接返回對應的數據庫對象就好。不需要調用者自己初始化，減少了寫錯密碼等等這些錯誤。調用者只負責使用，不需要管怎麽去創建、初始化對象。

還有，如果一個類有多個構造方法（構造的重寫），我們也可以將它抽出來，放到工廠中，一個構造方法對應一個工廠方法並命名一個友好的名字，這樣我們就不再只是根據參數的不同來判斷，而是可以根據工廠的方法名來直觀判斷將要創建的對象的特點。這對於使用者來說，體驗比較好。