工廠模式
工廠模式（Factory Pattern）是 Java 中最常用的設計模式之一。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
在工廠模式中，我們在創建對象時不會對客戶端暴露創建邏輯，並且是通過使用一個共同的接口來指向新創建的對象。
介紹
意圖：定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。
主要解決：主要解決接口選擇的問題。
何時使用：我們明確地計劃不同條件下創建不同實例時。
如何解決：讓其子類實現工廠接口，返回的也是一個抽象的產品。
關鍵代碼：創建過程在其子類執行。
應用實例： 1、您需要一輛汽車，可以直接從工廠裏面提貨，而不用去管這輛汽車是怎麼做出來的，以及這個汽車裏面的具體實現。 2、Hibernate 換數據庫只需換方言和驅動就可以。
優點： 1、一個調用者想創建一個對象，只要知道其名稱就可以了。 2、擴展性高，如果想增加一個產品，只要擴展一個工廠類就可以。 3、屏蔽產品的具體實現，調用者只關心產品的接口。
缺點：每次增加一個產品時，都需要增加一個具體類和對象實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。
使用場景： 1、日誌記錄器：記錄可能記錄到本地硬盤、系統事件、遠程服務器等，用戶可以選擇記錄日誌到什麼地方。 2、數據庫訪問，當用戶不知道最後系統採用哪一類數據庫，以及數據庫可能有變化時。 3、設計一個連接服務器的框架，需要三個協議，"POP3"、"IMAP"、"HTTP"，可以把這三個作爲產品類，共同實現一個接口。
注意事項：作爲一種創建類模式，在任何需要生成複雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜對象適合使用工廠模式，而簡單對象，特別是只需要通過 new 就可以完成創建的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。
工廠模式的作用？爲什麼要使用工廠模式？
工廠模式的實現方式和原理都不難理解和掌握。但是，在學習完之後，發現網上給的例子，根本體現不了工廠模式的作用。先不說存在有的例子本身就是錯誤的，主要是例子中的代碼太簡單，可以說沒必要用工廠模式，只不過是爲了說明實現方式和原理。所以，會產生一種錯覺：還不如直接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.類本身有好多子類，這些類的創建過程在業務中容易發生改變，或者對類的調用容易發生改變。