設計模式--工廠方法模式（Factory Method Pattern）

定義

定義一個用於建立物件的介面，讓子類決定例項化那個類。

使用場景

• 在任何需要生成複雜物件的地方，都可以使用工廠方法模式。
• 客戶端只知道傳入工廠類的引數，對於如何建立物件不關心：客戶端既不需要關心建立細節，甚至連類名都不需要記住，只需要知道型別所對應的引數

UML類圖

簡單工廠：

工廠方法：

  工廠方法模式是簡單工廠模式的進一步抽象和推廣。由於使用了物件導向的多型性，工廠方法模式保持了簡單工廠模式的優點，而且克服了它的缺點。在工廠方法模式中，核心的工廠類不再負責所有產品的建立，而是將具體建立工作交給子類去做。這個核心類僅僅負責給出具體工廠必須實現的介面，而不負責哪一個產品類被例項化這種細節，這使得工廠方法模式可以允許系統在不修改工廠角色的情況下引進新產品。

使用反射實現工廠方法模式：

public abstract class Factory {
    public abstract <T extends Product> T createProduct(Class<T> clz);
}

public class ConcreteFactory extends Factory {

    @Override
    public <T extends Product> T createProduct(Class<T> clz) {
        Product p = null;
        try {
            p = (Product) Class.from(clz.getName()).newInstance();
        } catch(Exception e) {
       }
        return (T) p;
    }
}
複製程式碼

優點

• 在工廠方法模式中，工廠方法用來建立客戶所需要的產品，同時還向客戶隱藏了哪種具體產品類將被例項化這一細節，使用者只需要關心所需產品對應的工廠，無須關心建立細節，甚至無須知道具體產品類的類名。
• 基於工廠角色和產品角色的多型性設計是工廠方法模式的關鍵。它能夠使工廠可以自主確定建立何種產品物件，而如何建立這個物件的細節則完全封裝在具體工廠內部。工廠方法模式之所以又被稱為多型工廠模式，是因為所有的具體工廠類都具有同一抽象父類。
• 使用工廠方法模式的另一個優點是在系統中加入新產品時，無須修改抽象工廠和抽象產品提供的介面，無須修改客戶端，也無須修改其他的具體工廠和具體產品，而只要新增一個具體工廠和具體產品就可以了。這樣，系統的可擴充套件性也就變得非常好，完全符合“開閉原則”。

缺點

• 在新增新產品時，需要編寫新的具體產品類，而且還要提供與之對應的具體工廠類，系統中類的個數將成對增加，在一定程度上增加了系統的複雜度，有更多的類需要編譯和執行，會給系統帶來一些額外的開銷。
• 由於考慮到系統的可擴充套件性，需要引入抽象層，在客戶端程式碼中均使用抽象層進行定義，增加了系統的抽象性和理解難度，且在實現時可能需要用到DOM(Document Object Model)、反射等技術，增加了系統的實現難度。