【設計模式】工廠模式

相對來說，寫的比較亂，但是看一下實例，其實理解很快

抽象工廠模式（這裡主要介紹抽象工廠模式）

核心的工廠類不再負責所有對象的創建，而是將具體的創建工作交給子類去做。這個類則搖身一變變成了一個抽象工廠角色，僅僅負責給出具體工廠子類必須實現的介面。
舉個例子：
我有個雞廠，我準備養雞，可以養母雞和公雞，但是母雞或者公雞有黃雞和黑雞（這就是舉個例子，不要太在意是否是正常的），
有一個抽象工廠，生產雞的工廠：

/**
 * @Description 總工廠
 */
public interface Factory{

    public Chicken getChicken(String name) throws InstantiationException, IllegalAccessException;
}

它有兩個實現類，分別是生產母雞的工廠和生產公雞的工廠：

/**
 * @Description 創建具體工廠類（繼承抽象工廠類），定義創建對應具體產品實例的方法；
 */
public class ChickenFactoryGirl implements Factory{
    @Override
    public Chicken getChicken(String name) throws InstantiationException, IllegalAccessException {
        if ("YellowGirlChicken".equalsIgnoreCase(name)) {
            return YellowGirlChicken.class.newInstance();
        } else if ("BlackGirlChicken".equalsIgnoreCase(name)) {
            return BlackGirlChicken.class.newInstance();
        }else{
            return null;
        }
    }
}
/**
 * @Description 創建具體工廠類（繼承抽象工廠類），定義創建對應具體產品實例的方法；
 */
public class ChickenFactoryMan implements Factory{
    @Override
    public Chicken getChicken(String name) throws InstantiationException, IllegalAccessException {
        if ("YellowManChicken".equalsIgnoreCase(name)) {
            return YellowManChicken.class.newInstance();
        } else if ("BlackManChicken".equalsIgnoreCase(name)) {
            return BlackManChicken.class.newInstance();
        }else{
            return null;
        }
    }
}

抽象產品角色，一隻雞：

/**
 * @Description 產品的抽象介面
 */
public interface Chicken {

    /**
     * 獲得相應的雞
     */
    public void get();
}

具體產品角色：

public class BlackGirlChicken implements Chicken{

    /**
     * 這叫做黑雞
     */
    @Override
    public void get() {
        System.out.println("這是一隻黑母雞");
    }
}
public class BlackManChicken implements Chicken{
    @Override
    public void get() {
        System.out.println("這是一隻黑公雞");
    }
}
public class YellowManChicken implements Chicken{
    @Override
    public void get() {
        System.out.println("這是一隻黃公雞");
    }
}
public class YellowGirlChicken implements Chicken{

    /**
     * 這叫做黃雞
     */
    @Override
    public void get() {
        System.out.println("這是一隻黃母雞");
    }
}

模擬客戶端調用，實例化出一個具體的工廠角色，根據傳入的參數返回不同的產品角色：

public class User {
    public static void main(String[] args) throws InstantiationException, IllegalAccessException {
        ChickenFactoryMan chickenFactoryMan = new ChickenFactoryMan();
        ChickenFactoryGirl chickenFactoryGirl = new ChickenFactoryGirl();
        Chicken yellowGirlChicken = chickenFactoryGirl.getChicken("YellowGirlChicken");
        yellowGirlChicken.get();
        Chicken blackGirlChicken = chickenFactoryGirl.getChicken("BlackGirlChicken");
        blackGirlChicken.get();
        Chicken yellowManChicken = chickenFactoryMan.getChicken("YellowManChicken");
        yellowManChicken.get();
        Chicken blackManChicken = chickenFactoryMan.getChicken("BlackManChicken");
        blackManChicken.get();

    }
}

總結：

對於抽象工廠類，其實是可以通過不同的品種種類來進行工廠創建，這樣就不會有工廠方式模式中的增加一個就創建一個工廠
那這個就是要在我們的產品族中增加一類產品，同時再增加一個工廠就可以解決這個問題；還有一個非常大的有點，高內聚，低耦合，在一個較大的項目組，產品是由一批人定義開發的，但是提供其他成員訪問的時候，只要提供工廠方法和產品的介面，也就是說只需要提供Interface 和抽象工廠，當然也可以提供具體工廠實現，根據實際情況來吧， 就可以產生自己需要的對象和方法。可擴展性很高。
在一個工廠里聚合多個同類產品！
缺點：產品族擴展非常困難，要增加一個系列的某一產品，既要在抽象的 Creator 裡加代碼，又要在具體的裡面加代碼。

產品族難擴展，產品等級易擴展。
總的來說，不同的工廠模式有不同的好處吧，也可以都嘗試一下，源碼裡面其實都會有一定的實現！

工廠方法模式

介紹

簡單來說就是通過定義工廠父類負責定義創建對象的公共介面，而子類則負責生成具體的對象。

作用

和簡單工廠模式不同，就是為瞭解決問題產生的
這裡將類的具體產品的創建（實例化）交給了工廠類的子類（具體工廠）來進行實現，這裡會由子類來進行選擇生產

工廠方法模式把具體產品的創建推遲到工廠類的子類（具體工廠）中，此時工廠類不再負責所有產品的創建，而只是給出具體工廠必須實現的介面，這樣工廠方法模式在添加新產品的時候就不修改工廠類邏輯而是添加新的工廠子類

實例

還是雞廠，作為一個賣雞的專業商戶，隨著買雞業務的增多，我自己生產的雞品類越來越多，這時候我需要專門來進行養雞的工廠來養雞，這樣我不會在乎這些工廠怎麼養雞的，我只會從這些工廠裡面拿雞，然後A類工廠拿到了訂單進行生產，後面又增加B類雞業務，然後置辦了另一個工廠B來進行生產B類雞，這裡A雞廠就不需要進行改變，也不會發生業務混淆的問題
工廠的公共介面，總雞廠

/**
 * @Description 總工廠
 */
public interface Factory{

    public Chicken getChicken() throws InstantiationException, IllegalAccessException;
}

創建具體工廠類（繼承抽象工廠類），定義創建對應具體產品實例的方法；具體生產雞的工廠

/**
 * @Description 創建具體工廠類（繼承抽象工廠類），定義創建對應具體產品實例的方法；
 */
public class ChickenFactoryA implements Factory{


    @Override
    public Chicken getChicken() throws InstantiationException, IllegalAccessException {
        return BlackChicken.class.newInstance();
    }
}
/**
 * @Description 創建具體工廠類（繼承抽象工廠類），定義創建對應具體產品實例的方法；
 */
public class ChickenFactoryB implements Factory{
    @Override
    public Chicken getChicken() throws InstantiationException, IllegalAccessException {
        return YellowChicken.class.newInstance();
    }

}

創建一個養雞的介面產品類

/**
 * @Description 產品的抽象介面
 */
public interface Chicken {

    /**
     * 獲得相應的雞
     */
    public void get();
}

接下來創建具體的產品類

/**
 * @Description 黃雞對抽象產品介面的實現
 */
public class BlackChicken implements Chicken{

    /**
     * 這叫做黑雞
     */
    @Override
    public void get() {
        System.out.println("這是一隻黑雞");
    }
}

/**
 * @Description 黃雞對抽象產品介面的實現
 */
public class YellowChicken implements Chicken{

    /**
     * 這叫做黃雞
     */
    @Override
    public void get() {
        System.out.println("這是一隻黃雞");
    }
}

優點

• 更符合開-閉原則 ，新增一種產品時，只需要增加相應的具體產品類和相應的工廠子類即可
• 符合單一職責原則 ， 每個具體工廠類只負責創建對應的產品

缺點

• 添加產品，雖然生產產品不會很複雜，但隨著產品種類的增加，系統類的個數會不斷增加，會不斷增加系統的開銷
• 雖然保證了工廠方法內的對修改關閉，但對於使用工廠方法的類，如果要更換另外一種產品，仍然需要修改實例化的具體工廠類；
• 一個工廠只能創建一個產品

總結

還是比較適合簡單一點的生產環境，比簡單生產模式更加安全合理，但是業務的增加會導致系統開銷的增加，這樣是不合理的，所以對於簡單的業務環境會比較適合，會造成類爆炸

簡單工廠模式

簡單介紹一下簡單工廠模式：就是我作為一個商家，隨著業務不斷拓寬，生產的產品不斷增多，這時候我需要一個專門的來工廠進行生產需要的產品，然後商家只需要從工廠來拿貨，而不需要自己負責所有。

Factory：工廠類，負責實現內部邏輯，創建的產品類可以被外界直接調用，創建所需要的產品對象
IProduct：抽象產品類，所有產品對象的父類，負責所有實例的共有的公共介面
Product：具體產品類

這種情況下可以使用

• 工廠類負責創建的對象相對來說比較少，業務邏輯不會太複雜
• 客戶端只知道傳入工廠類的參數，對於如何創建對象不會關心；客戶端既不需要關心創建細節，甚至連類名都不需要記住，只需要知道類型所對應的參數。
• JDK類庫中就廣泛使用了簡單工廠模式，如工具類java.text.DateFormat，它用於格式化一個本地日期或者時間。

實例

作為一個賣雞的專業商戶，隨著買雞業務的增多，我自己生產的雞品類越來越多，這時候我需要一個專門來進行養雞的工廠來養雞，這樣我不會在乎這個工廠怎麼養雞的，我只會從這個工廠裡面拿雞

創建一個養雞的介面產品類

/**
 * @Description 產品的抽象介面
 */
public interface Chicken {

    /**
     * 獲得相應的雞
     */
    public void get();
}

接下來創建具體的產品類

/**
 * @Description 黃雞對抽象產品介面的實現
 */
public class BlackChicken implements Chicken{

    /**
     * 這叫做黑雞
     */
    @Override
    public void get() {
        System.out.println("這是一隻黑雞");
    }
}

/**
 * @Description 黃雞對抽象產品介面的實現
 */
public class YellowChicken implements Chicken{

    /**
     * 這叫做黃雞
     */
    @Override
    public void get() {
        System.out.println("這是一隻黃雞");
    }
}

創建一個工廠類，它提供了一個靜態方法getChicken用來養雞。你只需要傳入你想生產的雞的種類，它就會實例化相應的雞對象：

/**
 * @Description 雞的加工廠
 */
public class ChickenFactory {

    public static Chicken getChicken(String type) throws InstantiationException, IllegalAccessException {
        if("BlackChicken".equalsIgnoreCase(type)){
            return BlackChicken.class.newInstance();
        }else if("YellowChicken".equalsIgnoreCase(type)){
            return YellowChicken.class.newInstance();
        }else{
            System.out.println("找不到對應的實例化類");
            return null;
        }
    }
}

測試一下（雞哥就是不一樣，要啥雞有啥雞）

/**
 * @Description
 */
public class User {
    public static void main(String[] args) throws InstantiationException, IllegalAccessException {
        Chicken blackChicken = ChickenFactory.getChicken("BlackChicken");
        Chicken yellowChicken = ChickenFactory.getChicken("YellowChicken");
        if(yellowChicken != null){
            yellowChicken.get();
        }

    }
}

優點

有點我看了好多博客，說實話認真看的沒多少

• 就是我不需要記住具體的實現產品類，我只需要記住參數，這樣可能會舒服一些
• 我增加或者更換新的產品類時，我不需要對以前的進行修改，只需要加一個新的就行

缺點

• 由於工廠類集中了所有實例的創建邏輯，這就直接導致一旦這個工廠出了問題，所有的客戶端都會受到牽連，就是工廠出問題，我們就都會出問題，這樣不安全
• 當我們的產品種類太多的時候，我們可能會混淆產品，這裡就需要進行各種判斷，所以這裡違背了“單一原則”
  （單一原則：一個類所承擔的職責不能夠太多，這裡就產生了單一原則，一個類只能負責一個功能領域的相應職責，對於一個類來說，只能由一個引起它變化的原因）
• 簡單工廠模式違背了“開放封閉原則”，就是違背了“系統對擴展開放，對修改關閉”的原則，因為當我新增加一個產品的時候必須修改工廠類，相應的工廠類就需要重新編譯一遍。就是系統擴展困難，一旦添加新產品就不得不修改工廠邏輯
  （開放封閉原則：軟體一般來說時可擴展但不可修改的，也就是有了新的業務只能對現有的類上進行擴展，而不能進行修改。類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改）

總結

對於簡單的工廠模式來說，可以用，但是不能用太多，只適合在需求不多的時候使用，比如自己寫一個小型測試類