設計模式--工廠方法模式（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)、反射等技術，增長了系統的實現難度。