摘要：缺點需要慎重考慮是否增加工廠類進行管理，因為會增加代碼的復雜度使用場景工廠模式是創建型模式的一種，其實就等價于對象，但是否將對象改造成工廠模式，使我們需要衡量的。

最近北京天氣越來越冷了，同在北京的小伙伴大家注意保暖。不扯廢話了，讓我們直接進入到工廠模式的學習.

定義一個用于創建對象的接口，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到子類。

優點：良好的封裝性，代碼結構清晰，擴展性非常強。屏蔽產品類，產品的實際創建在工廠類中，產品類的實現如何變化，調用者都不需要關心，只要關心產品的接口即可。

缺點:需要慎重考慮是否增加工廠類進行管理，因為會增加代碼的復雜度

工廠模式是創建型模式的一種，其實就等價于new對象，但是否將new對象改造成工廠模式，使我們需要衡量的。工廠模式是一個非常靈活的框架設計，比如我們使用的jdbc，數據庫分為oracle和mysql，這些都是產品類，若我們新增一種數據庫，只需要增加其產品類就行，符合開閉原則。

//所有英雄的父類
public abstract class Hero {

    public void fromGame() {
        System.out.println("i am come from lol");
    }
    //英雄類型
    abstract void typeOf();
    //英雄特點
    abstract void feature();
}

public class Mage extends Hero {
    @Override
    void typeOf() {
        System.out.println("我是法師");
    }

    @Override
    void feature() {
        System.out.println("我的法術傷害很爆炸");
    }
}

public class Tank extends Hero {
    @Override
    void typeOf() {
        System.out.println("我是坦克");
    }

    @Override
    void feature() {
        System.out.println("我很肉，我抗性很高");
    }
}

public class Assassin extends Hero {
    @Override
    void typeOf() {
        System.out.println("我是刺客");
    }

    @Override
    void feature() {
        System.out.println("我瞬間傷害很爆炸");
    }
}

就先定義三種類型英雄，其他省略,畢竟我們是學設計模式不是打游戲的....

//抽象工廠，定義創建英雄方法
public abstract class AbstractFactory {

    abstract T createHero(Class clazz) throws ClassNotFoundException, IllegalAccessException, InstantiationException;
}

//工廠真正的實現類
public class Factory extends AbstractFactory {
    @Override
     T createHero(Class clazz) {
        Hero hero = null;
        try {
            hero = (Hero) Class.forName(clazz.getName()).newInstance();
        } catch (Exception e) {
            System.out.println("class文件有問題");
        }
        return (T) hero;
    }
}

//測試類
public class Client {

    public static void main(String[] args) throws IllegalAccessException, InstantiationException, ClassNotFoundException {
        AbstractFactory factory = new Factory();
        Hero hero = factory.createHero(Mage.class);
        Hero hero2 = factory.createHero(Assassin.class);
        Hero hero3 = factory.createHero(Tank.class);

        hero.fromGame();hero.typeOf();hero.feature();
        hero2.fromGame();hero2.typeOf();hero2.feature();
        hero3.fromGame();hero3.typeOf();hero3.feature();
    }
}
測試結果：
i am come from lol
我是法師
我的法術傷害很爆炸
i am come from lol
我是刺客
我瞬間傷害很爆炸
i am come from lol
我是坦克
我很肉，我抗性很高

這就是最常見的工廠模式，一定會有小伙伴說你少定義了adc和support。我們現在來思考一下，在這個基礎框架上如何將adc和support加進去。其實我們只需要定義adc和support類，讓其繼承于hero，工廠類什么都不用改，測試類或高層模塊就可以直接使用，是不是很流弊....

簡單工廠模式

假如一個模塊僅需要一個工廠類，基于這樣的業務，我們根本沒必要在測試類或高層模塊中將工廠類給生產出來，使用其靜態方法就好了。應該去除抽象工廠類，修改工廠實現類為靜態方法即可.代碼示例:

public class Factory  {
     static   T createHero(Class clazz) {
        Hero hero = null;
        try {
            hero = (Hero) Class.forName(clazz.getName()).newInstance();
        } catch (Exception e) {
            System.out.println("class文件有問題");
        }
        return (T) hero;
    }
}

public class Client {

    public static void main(String[] args) throws IllegalAccessException, InstantiationException, ClassNotFoundException {
        Hero hero = Factory.createHero(Mage.class);
        Hero hero2 = Factory.createHero(Assassin.class);
        Hero hero3 = Factory.createHero(Tank.class);

        hero.fromGame();hero.typeOf();hero.feature();
        hero2.fromGame();hero2.typeOf();hero2.feature();
        hero3.fromGame();hero3.typeOf();hero3.feature();
    }
}

運行結果不會有任何變化，我們的uml類圖也會變得簡單，調用者也就是測試類或者項目中的高層模塊調用起來也會簡單，其缺點就是工廠類擴展比較麻煩，不符合開閉原則。

多個工廠類

原來的工廠負責所有類型英雄的創建，職責有點太多了。多個工廠類顧名思義就是對工廠類進行拆分，使其符合單一職責原則。當我們遇到一個非常復雜的項目時，產品類會有很多，并且在我們獲得一個產品類很可能都需要對其初始化，不同的產品類會有不同的實現，假如都寫在一個工廠類里，會出現很長很長的if/else或者swtich之類得判斷語句，這種代碼是有毒的！假如你的代碼中有類似代碼，就應該考慮下能不能給重構了.
UML圖:

public abstract class AbstractFactory {

    abstract Hero createHero();
}

public class AssassianFactory extends AbstractFactory {

    @Override
    Hero createHero() {
        return new Assassin();
    }
}

public class TankFactory extends AbstractFactory {

    @Override
    Hero createHero() {
        return new Tank();
    }
}

public class MageFactory extends AbstractFactory {

    @Override
    Hero createHero() {
        return new Mage();
    }
}

public class Client {

    public static void main(String[] args) throws IllegalAccessException, InstantiationException, ClassNotFoundException {
        Hero mageHero = new MageFactory().createHero();
        Hero tankHero = new TankFactory().createHero();
        Hero assassinHero = new AssassianFactory().createHero();
    }
}

每一個產品類都對應了一個工廠，好處就是職責清晰，結構簡單。壞處就是我們擴展新的產品時，需要額外擴展一個工廠類，增加了擴展的難度

延遲初始化

一個對象被消費完畢后，并不立即釋放，工廠類保持其初始化，等待再次被使用.

public class HeroFactory {
    private static final Map heroMap = new HashMap<>();

    public static synchronized Hero createHero(String type) {
        Hero hero = null;
        if (heroMap.containsKey(type)) {
            return heroMap.get(type);
        } else {
            if (type.equals("mage")) {
                hero = new Mage();
            } else if (type.equals("tank")) {
                hero = new Tank();
            } else {
                hero = new Assassin();
            }
            heroMap.put(type, hero);
        }
        return hero;
    }

}

我們定義了一個靜態常量heroMap,在內存中對工廠創建的對象進行延遲化，方便下次調用。同時也非常方便擴展，比如我們在玩英雄聯盟，知道雙方英雄不會超過10個，可以根據map的長度，判斷內存中最多的hero實例數。

工廠模式是一個很常見很優秀的設計模式，我們應該多思考工廠方法如何應用，而且工廠模式和原型模式單例模式結合起來會用更多神奇的設計！不用著急，我們慢慢來...