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

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

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

首先，工廠模式是為了解耦：把物件的建立和使用的過程分開。就是Class A 想呼叫 Class B ，那麼A只是呼叫B的方法，而至於B的例項化，就交給工廠類。

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

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

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

舉個例子：

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

這個工廠就可以把資料庫連線需要的使用者名稱，地址，密碼等封裝好，直接返回對應的資料庫物件就好。不需要呼叫者自己初始化，減少了寫錯密碼等等這些錯誤。呼叫者只負責使用，不需要管怎麼去建立、初始化物件。

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

工廠模式適用的一些場景（不僅限於以下場景）：

1. 物件的建立過程/例項化準備工作很複雜，需要初始化很多引數、查詢資料庫等。

2.類本身有好多子類，這些類的建立過程在業務中容易發生改變，或者對類的呼叫容易發生改變。