【設計模式】工廠模式
工廠模式（Factory Pattern）是 Java 中最常用的設計模式之一。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
在工廠模式中，我們在創建對象時不會對客戶端暴露創建邏輯，並且是通過使用一個共同的接口來指向新創建的對象。
簡單工廠也稱為靜態工廠，一般可以用靜態方法（類方法）來獲取對象。
基本介紹
-
意圖：定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。
-
主要解決：主要解決接口選擇的問題。
-
何時使用：我們明確地計劃不同條件下創建不同實例時。
-
如何解決：讓其子類實現工廠接口，返回的也是一個抽象的產品。
-
關鍵代碼：創建過程在其子類執行。
- 應用實例：
- 您需要一輛汽車，可以直接從工廠裏面提貨，而不用去管這輛汽車是怎麼做出來的，以及這個汽車裏面的具體實現。
- Hibernate 換數據庫只需換方言和驅動就可以。
- 優點：
- 一個調用者想創建一個對象，只要知道其名稱就可以了。
- 擴展性高，如果想增加一個產品，只要擴展一個工廠類就可以。
- 屏蔽產品的具體實現，調用者只關心產品的接口。
-
缺點：每次增加一個產品時，都需要增加一個具體類和對象實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。
- 使用場景：
- 日誌記錄器：記錄可能記錄到本地硬盤、系統事件、遠程服務器等，用戶可以選擇記錄日誌到什麼地方。
- 數據庫訪問，當用戶不知道最後系統採用哪一類數據庫，以及數據庫可能有變化時。
- 設計一個連接服務器的框架，需要三個協議，”POP3″、”IMAP”、”HTTP”，可以把這三個作為產品類，共同實現一個接口。
注意事項：作為一種創建類模式，在任何需要生成複雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜對象適合使用工廠模式，而簡單對象，特別是只需要通過 new 就可以完成創建的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。
概括
工廠模式（Factory Pattern）是 Java 中最常用的設計模式之一。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
在工廠模式中，我們在創建對象時不會對客戶端暴露創建邏輯，並且是通過使用一個共同的接口來指向新創建的對象。
- 簡單工廠模式是屬於創建型模式，是工廠模式的一種。簡單工廠模式是由一個工廠對象決定創建出哪一種產品類的實例。簡單工廠模式是工廠模式家族中最簡單實用的模式。
- 簡單工廠模式：定義了一個創建對象的類，由這個類來封裝實例化對象的行為(代碼)
- 在軟件開發中，當我們會用到大量的創建某種、某類或者某批對象時，就會使用到工廠模式。
一句話概括工廠模式
- 簡單工廠：一個工廠類，一個產品抽象類。
- 工廠方法：多個工廠類，一個產品抽象類。
- 抽象工廠：多個工廠類，多個產品抽象類。
生活中的工廠模式
- 簡單工廠類：一個麥當勞店，可以生產多種漢堡。
- 工廠方法類：一個麥當勞店，可以生產多種漢堡。一個肯德基店，也可以生產多種漢堡。
- 抽象工廠類：百勝餐飲集團下有肯德基和百事公司，肯德基生產漢堡，百事公司生成百事可樂。
其實工廠模式就如它的名字一般，是個密不透風的工廠。我們只需要把我們需要的清單交給它，他就能做出相應的物品給我們，而不需要我們親力親為，親手去製造物品。如 我們需要汽車 car，我們不需要自己
new Car()創建一個汽車對象，而是只需要將 “car”（枚舉字符串）這種清單交給工廠就可以了。
類圖：
角色分析：
- Product：是產品接口
- Product1、2、3：是具體產品
- Factory：是工廠類，裏面有靜態方法
createProduct()，負責創建不同的產品。
我的理解
其實工廠模式就如它的名字一般，是個密不透風的工廠。我們只需要把我們需要的清單交給它，他就能做出相應的物品給我們，而不需要我們親力親為，親手去製造物品。如 我們需要汽車 car，我們不需要自己new Car()創建一個汽車對象，而是只需要將 “car”（枚舉字符串）這種清單交給工廠就可以了。
比如說有個飯館，會做上百種菜，飯館裏面的老闆，還有老顧客，他們當然都知道這個飯館到底賣哪些菜。但是來了一個新來的顧客 他一時間當然不知道這個飯館到底賣哪些菜，這樣的話，我們就需要一個菜單來將這些菜的創建給聚合起來，方便管理與查找。不然的話，上百種菜零零散散 很難管理。
不然的話，新顧客需要點菜就必須得依賴每一種菜他才能點，所以我們需要簡單工廠來幫我們管理、解耦。
比如說我們這個系統需要一個外賣系統和一個現場購買系統，這兩個系統都需要創建披薩，如果重複創建會帶來很多冗餘，所以需要工廠。
工廠也可以充當一個緩衝層來用，將來如果有什麼變化的話，工廠可以起到緩衝的作用，避免因為變化而使系統出現錯誤，
因為緩衝，底層代碼的修改可以不影響到頂層代碼的功能。
這是一個樹形的創建型設計模式，和包的作用一樣，希望用到什麼功能就去哪個功能的工廠去找。
個人感覺，這些工廠，抽象工廠，都是為了讓類的聲明、對象的構造更有層次感，就好像樹形圖一樣，以抽象工廠為根，以不同工廠為枝葉，以工廠的產品為葉子。不然一下這個類，一下那個類，會很凌亂。
應用實例
看一個具體的需求
看一個披薩的項目：要便於披薩種類的擴展，要便於維護
- 披薩的種類很多(比如 GreekPizz、CheesePizz 等)
- 披薩的製作有 prepare，bake, cut, box
- 完成披薩店訂購功能。
使用傳統方式
-
思路分析(類圖)
- 編寫 OrderPizza.java 去訂購需要的各種 Pizza
public class OrderPizza {
public static void main(String[] args) {
//我們需要什麼披薩就創建什麼披薩
//創建芝士披薩
Pizza pizza = new CheesePizza();
//Pizza pizza = new PepperPizza();
//Pizza pizza = new GreekPizza();
}
}傳統的方式的優缺點：
- 優點：比較好理解，簡單易操作。
- 缺點：如果我們有幾十種不同的披薩，我們程序員就要硬生生記住這些不同的披薩類名，還不能出錯。
若服務器中披薩的類名一改，我們客戶端使用的披薩類名也要改。
改進的思路分析：
- 分析：修改代碼可以接受，但是如果我們在其它的地方也有創建 Pizza 的代碼，就意味着，也需要修改，而創建 Pizza
的代碼，往往有多處。 - 思路：把創建 Pizza 對象封裝到一個類中，這樣我們有新的 Pizza 種類時，只需要修改該類就可，其它有創建到 Pizza
對象的代碼就不需要修改了。 => 簡單工廠模式
使用簡單工廠模式
簡單工廠模式的設計方案: 定義一個可以實例化 Pizaa 對象的類，封裝創建對象的代碼。
簡單工廠模式 也叫 靜態工廠模式，可以將方法靜態化為類方法，直接用類調用。
類圖：
代碼示例：
package com.atguigu.factory.simplefactory.pizzastore.order;
import com.atguigu.factory.simplefactory.pizzastore.pizza.CheesePizza;
import com.atguigu.factory.simplefactory.pizzastore.pizza.GreekPizza;
import com.atguigu.factory.simplefactory.pizzastore.pizza.PepperPizza;
import com.atguigu.factory.simplefactory.pizzastore.pizza.Pizza;
//簡單工廠類
public class SimpleFactory {
//更加 orderType 返回對應的 Pizza 對象
public Pizza createPizza(String orderType) {
Pizza pizza = null;
System.out.println("使用簡單工廠模式");
if (orderType.equals("greek")) {
pizza = new GreekPizza();
pizza.setName(" 希臘披薩 ");
} else if (orderType.equals("cheese")) {
pizza = new CheesePizza();
pizza.setName(" 奶酪披薩 ");
} else if (orderType.equals("pepper")) {
pizza = new PepperPizza();
pizza.setName("胡椒披薩");
}
return pizza;
}
//簡單工廠模式 也叫 靜態工廠模式
public static Pizza createPizza2(String orderType) {
Pizza pizza = null;
System.out.println("使用簡單工廠模式 2");
if (orderType.equals("greek")) {
pizza = new GreekPizza();
pizza.setName(" 希臘披薩 ");
} else if (orderType.equals("cheese")) {
pizza = new CheesePizza();
pizza.setName(" 奶酪披薩 ");
} else if (orderType.equals("pepper")) {
pizza = new PepperPizza();
pizza.setName("胡椒披薩");
}
return pizza;
}
}優化：
我看到網上有很多用反射來使披薩不用去一個一個 if-else。
其實使用反射是一種不錯的辦法，但反射也是從類名反射而不能從類反射！
先看一下工廠模式是用來幹什麼的——屬於創建模式，解決子類創建問題的。換句話來說，調用者並不知道運行時真正的類名，只知道從「Circle”可以創建出一個shape接口的類，至於類的名稱是否叫’Circle”，調用者並不知情。所以真正的對工廠進行擴展的方式（防止程序員調用出錯）可以考慮使用一個枚舉類（防止傳入參數時，把circle拼寫錯誤）。
如果調用者參肯定類型是Circle的話，那麼其工廠沒有存在的意義了！
比如 IShape shape = new Circle();這樣不是更好？也就是說調用者有了Circle這個知識是可以直接調用的，根據DP（迪米特法則）其實調用者並不知道有一個Circle類的存在，他只需要知道這個IShape接口可以計算圓面積，而不需要知道；圓這個類到底是什麼類名——他只知道給定一個」circle”字符串的參數,IShape接口可以自動計算圓的面積就可以了！
其實在.net類庫中存在這個模式的的一個典型的。但他引入的另一個概念「可插入編程協議」。
那個就是WebRequest req = WebRequest.Create(“//ccc……”);可以自動創建一個HttpWebRequest的對象，當然，如果你給定的是一個ftp地址，他會自動創建一個FtpWebRequest對象。工廠模式中着重介紹的是這種通過某個特定的參數，讓你一個接口去干對應不同的事而已！而不是調用者知道了類！
比如如果圓的那個類名叫”CircleShape「呢？不管是反射還是泛型都干擾了你們具體類的生成！其實這個要說明的問題就是這個，調用者（clinet)只知道IShape的存在，在創建時給IShape一個參數”Circle”,它可以計算圓的面積之類的工作，但是為什麼會執行這些工作，根據迪米特法則，client是不用知道的。
我想問一下那些寫筆記的哥們，如果你們知道了泛型，那麼為什麼不直接使用呢？幹嗎還需要經過工廠這個類呢？不覺得多餘了嗎？
如果，我只是說如果，如果所有從IShape繼承的類都是Internal類型的呢？而client肯定不會與IShape一個空間！這時，你會了現你根本無法拿到這個類名！
Create時使用註冊機制是一種簡單的辦法，比如使用一個枚舉類，把功能總結到一處。而反射也是一種最簡單的辦法，調用者輸入的名稱恰是類名稱或某種規則時使用，比如調用者輸入的是Circle，而類恰是CircleShape，那麼可以通過輸入+」Shape”字符串形成新的類名，然後從字符串將運行類反射出來！
工廠的創建行為，就這些作用，還被你們用反射或泛型轉嫁給了調用者（clinet)，那麼，這種情況下，要工廠類何用？！
使用枚舉類優化
優化一
增加枚舉類
public enum PizzaType {
GREEKPIZZA,
CHEESEPIZZA,
PEPPERPIZZA
}修改工廠類的工廠方法，個人建議工廠方法應該是靜態方法或者採用單例模式：
public class SimpleFactory {
public static Pizza createPizza(PizzaType type) {
switch(type) {
case GREEKPIZZA:
return new GreekPizza();
case CHEESEPIZZA:
return new CheesePizza();
case PEPPERPIZZA:
return new PepperPizza();
default:
throw new UnknownTypeException();
}
}
}最後是使用示例：
public class FactoryPatternDemo {
public static void main(String[] args) {
//獲取 GreekPizza 的對象
Pizza pizza1 = SimpleFactory.createPizza(PizzaType.GREEKPIZZA);
}
}優化二
public enum Factory {
//使用構造方法，構造枚舉類型對象
GREEKPIZZA(new GreekPizza(),"GREEKPIZZA"),
CHEESEPIZZA(new CheesePizza(),"CHEESEPIZZA"),
PEPPERPIZZA(new PepperPizza(),"PEPPERPIZZA");
// 成員變量，上面的構造方法就取決於這些成員變量
private Pizza pizza;
private String name;
// 普通方法
public static Shape getPizza(String name) {
for (Factory c : Factory.values()) {
if (c.name == name) {
return c.pizza;
}
}
return null;
}
// 構造方法
private Factory(Pizza pizza, String name) {
this.pizza = pizza;
this.name = name;
}
public String getName() {
return name;
}
public Pizza getPizza() {
return pizza;
}
public void setPizza(Pizza pizza) {
this.pizza = pizza;
}
public void setName(String name) {
this.name = name;
}
}public class FactoryPatternDemo {
public static void main(String[] args) {
//獲取 GreekPizza 的對象
/*使用枚舉類*/
Pizza pizza1 = Factory.getPizza("GREEKPIZZA");
Pizza pizza2 = Factory.getPizza("CHEESEPIZZA");
Pizza pizza3 = Factory.getPizza("PEPPERPIZZA");
}
}工廠模式小結
- 工廠模式的意義：
將實例化對象的代碼提取出來，放到一個類中統一管理和維護，達到和主項目的依賴關係的解耦。從而提高項目的擴展和維護性。 - 三種工廠模式（簡單工廠模式、工廠方法模式、抽象工廠模式）
- 設計模式的依賴抽象原則
- 創建對象實例時，不要直接 new 類, 而是把這個 new 類的動作放在一個工廠的方法中，並返回。有的書上說，變量不要直接持有具體類的引用。
- 不要讓類繼承具體類，而是繼承抽象類或者是實現 interface（接口）
- 不要覆蓋基類中已經實現的方法。
