工廠模式-Factory Pattern

意圖：

定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。

主要解決：

主要解決接口選擇的問題。

何時使用：

我們明確地計劃不同條件下創建不同實例時。

如何解決：

讓其子類實現工廠接口，返回的也是一個抽象的產品。

關鍵代碼：

創建過程在其子類執行。

應用實例：

1. 您需要一輛汽車，可以直接從工廠裏面提貨，而不用去管這輛汽車是怎麼做出來的，以及這個汽車裏面的具體實現。
2. Hibernate 換數據庫只需換方言和驅動就可以。

優點：

1. 一個調用者想創建一個對象，只要知道其名稱就可以了。
2. 擴展性高，如果想增加一個產品，只要擴展一個工廠類就可以。
3. 屏蔽產品的具體實現，調用者只關心產品的接口。

缺點：

每次增加一個產品時，都需要增加一個具體類和對象實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。

使用場景：

1. 日誌記錄器：記錄可能記錄到本地硬盤、系統事件、遠程服務器等，用戶可以選擇記錄日誌到什麼地方。
2. 數據庫訪問，當用戶不知道最後系統採用哪一類數據庫，以及數據庫可能有變化時。
3. 設計一個連接服務器的框架，需要三個協議，POP3、IMAP、HTTP，可以把這三個作爲產品類，共同實現一個接口。

注意事項：

作爲一種創建類模式，在任何需要生成複雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜對象適合使用工廠模式，而簡單對象，特別是只需要通過 new 就可以完成創建的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。

通用UML類圖：

通用源碼：

抽象產品類

public abstract class Product {
    //產品類的公共方法
    public void method1(){
        //業務邏輯處理
    }
    //抽象方法
    public abstract void method2();
}

具體產品類

public class ConcreteProduct1 extends Product {
    public void method2() {
        //業務邏輯處理
    }
}
public class ConcreteProduct2 extends Product {
    public void method2() {
        //業務邏輯處理
    }
}

抽象工廠類

public abstract class Creator {
    /*
    * 創建一個產品對象，其輸入參數類型可以自行設置
    * 通常爲String、Enum、Class等，當然也可以爲空
    */
    public abstract <T extends Product> T createProduct(Class<T> c);
}

具體工廠類

public class ConcreteCreator extends Creator {
    public <T extends Product> T createProduct(Class<T> c){
    Product product=null;
    try {
        product = (Product)Class.forName(c.getName()).newInstance();
    } catch (Exception e) {
        //異常處理
    }
        return (T)product;
    }
}

場景類

public class Client {
    public static void main(String[] args) {
        Creator creator = new ConcreteCreator();
        Product product = creator.createProduct(ConcreteProduct1.class);
        /*
        * 繼續業務處理
        */
    }
}

轉載來源：
http://www.runoob.com/design-pattern/factory-pattern.html
http://www.uml.org.cn/oobject/201404035.asp