摘要：工廠方法模式工廠方法模式是為了克服簡單工廠模式的缺點。抽象工廠模式抽象工廠模式主要在于應(yīng)對新系列的需求變化。此時架構(gòu)便可以升級為工廠方法模式。

在面向?qū)ο缶幊讨袆?chuàng)建一個對象通常通過new關(guān)鍵字來創(chuàng)建，但是往往在一些業(yè)務(wù)場景下，個別對象是一個比較復(fù)雜的bean。此時“創(chuàng)建對象”不光是new了，還需要一些額外的操作，比如填充數(shù)據(jù)，附屬對象的準備等等。如果我們想要得到這樣的一個對象，直接簡單粗暴的在需要的時候，創(chuàng)建、準備數(shù)據(jù)。。。做這些操作的話，那我么你的代碼將臃腫不堪，到處充斥著業(yè)務(wù)邏輯，業(yè)務(wù)需求變化時，就GG了。我們身為高貴的軟件工程師，必須保持著代碼潔癖，如何提升代碼質(zhì)量呢？那就運用到今天的主角：工廠模式。

工廠模式是代替new來創(chuàng)建對象的一種設(shè)計模式，作用是降低代碼耦合度，提升程序的易擴展性。

簡單工廠模式

工廠方法模式

抽象工廠模式

三種模式都是工廠模式，他們都具有工廠模式的優(yōu)點，抽象程度從上到下越來越高，分別都有不同的適用場景，接下來逐一介紹。

簡單工廠的角色分為3個

工廠

抽象產(chǎn)品

具體產(chǎn)品

舉例：
比如我正在“吃雞”，跳傘剛落地，急需一把槍防身.
有如下類

public abstract class Gun {
    private String name;

    public Gun(String name) {
        this.name = name;
    }
    
    public void shoot(){
        System.out.println(name);
    }
}


public class M416 extends Gun {

    public M416() {
        super("m416");
    }
}

public class Ak47 extends Gun {

    public Ak47() {
        super("ak47");
    }
}

沒有使用工廠模式時代碼是這樣的

Gun gun = new Ak47();
或
Gun gun = new M416();

使用了工廠模式時

public class SimpleFactory {
    public static Gun getGun(GunType gunType){
        switch (gunType){
            case AK47:
                return new Ak47();
            case M416:
                return new M416();
            default:
                return null;
        }
    }

    public enum GunType{
        AK47,M416;
    }
}

客戶端調(diào)用：

public class SimpleFactoryClient {

    public static void main(String[] args) {
        //得到ak47
        Gun gun = SimpleFactory.getGun(SimpleFactory.GunType.AK47);
        
        //得到m416
        gun = SimpleFactory.getGun(SimpleFactory.GunType.M416);
    }
}

這樣代碼就清晰多了，這就好比沒用工廠模式時自己要冒險去找槍，需要知道業(yè)務(wù)的細節(jié)。使用了工廠模式，只需要大喊一聲我要m4，就有快遞員把槍送到你面前，而不需要知道獲得槍的過程。

這就是簡單工程模式，簡單工程模式確實將代碼解耦了，但是如果我們想要awm呢？需要增加一種枚舉，然后多加一個case語句，這是不符合設(shè)計模式的開閉原則（對擴展開放，對修改關(guān)閉）。接下來我們介紹下一種，工廠方法模式。

工廠方法的角色分為4個

抽象工廠

具體工廠

抽象產(chǎn)品

具體產(chǎn)品

舉例：

之前簡單工廠中使用了switch case來判斷到底要返回哪個實例，此時我們可以將switch case給代替。
我們定義一個抽象的槍工廠

public interface GunFactory {
    Gun getGun();
}

然后分別定義具體的ak47工廠和m416工廠

public class Ak47Factory implements GunFactory {
    @Override
    public Gun getGun() {
        return new Ak47();
    }
}

public class M416Factory implements GunFactory {
    @Override
    public Gun getGun() {
        return new M416();
    }
}

客戶端調(diào)用：

public class FactoryClient {
    public static void main(String[] args) {
        //獲取ak47
        GunFactory gunFactory = new Ak47Factory();
        Gun gun = gunFactory.getGun();

        //獲取m416
        gunFactory = new M416Factory();
        gun = gunFactory.getGun();
    }
}

當我們需要獲得awm時，則只需要新增一個Awm類和一個AwmFactory讓其實現(xiàn)GunFactory即可，這樣避免了寫switch case，符合了開閉原則。

此時有的小伙伴可能會問，最初不適用工廠方法時是用new Ak47()來獲得槍，現(xiàn)在使用new Ak47Factory()不是和之前一樣嗎？說明下，這是我假設(shè)的ak47可能僅僅只是需要new以下，但在我們實際的場景中，有些bean的創(chuàng)建是及其復(fù)雜，他可能是其他開發(fā)人員負責的邏輯，你去對接時根本不需要了解其中的細節(jié)，只需要獲得僅此而已。工廠模式就是封裝了構(gòu)建產(chǎn)品的細節(jié)，客戶端根據(jù)想要的產(chǎn)品，選擇對應(yīng)的工廠就可獲得相應(yīng)的產(chǎn)品。

我們現(xiàn)在得到了槍，但是還沒有子彈和配件，此時我們想要直接得到一把滿配的槍。
但是子彈的類型有多種，配件的類型也有多種，此時我們又想到了為子彈和配件創(chuàng)建工廠，但是我們獲得一把槍滿配的槍并不需要知道怎么獲得子彈和配件，所以我們的槍工廠就要直接包含子彈工廠和配件工廠，因此我們的抽象工廠模式呼之欲出。

抽象工廠的角色分為4個

抽象工廠

具體工廠

抽象產(chǎn)品（多個相同主題）

具體產(chǎn)品

舉例：
首先我們創(chuàng)建子彈的類

public abstract class Bullet {
    protected String name;

    public Bullet(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public Bullet setName(String name) {
        this.name = name;
        return this;
    }
}

public class Ak47Bullet extends Bullet {

    public Ak47Bullet() {
        super("ak的子彈");
    }
}

public class M416Bullet extends Bullet {

    public M416Bullet() {
        super("m416的子彈");
    }
}

接著是子彈工廠

public interface BulletFactory {
    Bullet getBullet();
}

public class Ak47BulletFactory implements BulletFactory {
    @Override
    public Bullet getBullet() {
        return new Ak47Bullet();
    }
}

public class M416BulletFactory implements BulletFactory {
    @Override
    public Bullet getBullet() {
        return new M416Bullet();
    }
}

配件的代碼與其相同只不過是名字換一個，此時是不是發(fā)現(xiàn)我們的子彈工廠和我們之前實現(xiàn)的槍工廠其實是一模一樣的。我們都使用了工廠方法模式，但是我們最終想要獲得是完整的滿配的槍，即槍中包含了子彈和配件。所以抽象工廠模式就將一系列具有相同主題的工廠封裝在一起。
因此抽象工廠解決的范疇是產(chǎn)品族等級（完整的槍），工廠方法模式解決的范疇是產(chǎn)品等級（子彈、配件）。

槍工廠

public class Ak47Factory implements GunFactory {
    @Override
    public Gun getGun() {
        Bullet bullet = new Ak47Bullet();
        return new Ak47(bullet);
    }
}

public class Ak47 extends Gun {

    public Ak47(Bullet bullet) {
        super("ak47");
        this.setBullet(bullet);
    }
}

public abstract class Gun {
    private String name;

    private Bullet bullet;

    public Gun(String name) {
        this.name = name;
    }

    public void shoot(){
        System.out.println(name + "正在使用" + bullet.getName() + "射擊");
    }

    public Bullet getBullet() {
        return bullet;
    }

    public Gun setBullet(Bullet bullet) {
        this.bullet = bullet;
        return this;
    }
}

客戶端調(diào)用

public class FactoryClient {
    public static void main(String[] args) {
        //獲取ak47
        GunFactory gunFactory = new Ak47Factory();
        Gun gun = gunFactory.getGun();
        System.out.println(gun.getBullet());//ak的子彈

        //獲取m416
        gunFactory = new M416Factory();
        gun = gunFactory.getGun();
        System.out.println(gun.getBullet());//m416的子彈
    }
}

三種工廠方法都有各自的優(yōu)缺點，也有各自的試用場景

簡單工廠方法：工廠類含有必要的判斷邏輯，可以決定在什么時候創(chuàng)建哪一個產(chǎn)品類的實例，客戶端可以免除直接創(chuàng)建產(chǎn)品對象的責任，而僅僅"消費"產(chǎn)品。耦合度低。明確區(qū)分了各自的職責和權(quán)力，有利于整個軟件體系結(jié)構(gòu)的優(yōu)化。

工廠方法模式：工廠方法模式是為了克服簡單工廠模式的缺點。簡單工廠模式的工廠類隨著產(chǎn)品類的增加需要增加很多方法（或代碼），而工廠方法模式每個具體工廠類只完成單一任務(wù)，代碼簡潔。工廠方法模式完全滿足OCP，即它有非常良好的擴展性。

抽象工廠模式：抽象工廠模式主要在于應(yīng)對“新系列”的需求變化。分離了具體的類，一個抽象工廠創(chuàng)建了一個完整的產(chǎn)品系列，所以整個產(chǎn)品系列會立刻改變。它有利于產(chǎn)品的一致性。是對多個構(gòu)成產(chǎn)品的“零件”工廠的封裝，使一個切換產(chǎn)品主題變得極為容易。

其實在我們?nèi)粘Ｗ鲂枨髸r，代碼的架構(gòu)可能是一步一步演化的，最開始接到需求可能就是連三種產(chǎn)品，這是我們可能就設(shè)計成簡單工廠模式。之后產(chǎn)品增加多了，而且其他開發(fā)人員可能也要處理這邊的邏輯，則原先的switch case很有可能就會成為bug的伏筆。此時架構(gòu)便可以升級為工廠方法模式。再后來原來的產(chǎn)品變得龐大且復(fù)雜，需要將產(chǎn)品設(shè)計成多個零件構(gòu)成，此時架構(gòu)又可以升級成抽象工廠模式，將耦合度進一步降低，之后其他的開發(fā)者想要新增產(chǎn)品，一看結(jié)構(gòu)清晰明了，便可以高質(zhì)量的完成工作，早早下班回家。

設(shè)計模式幫助我們提升代碼質(zhì)量，每種設(shè)計模式都有其適合的場景，切勿過度設(shè)計，讓技術(shù)推動業(yè)務(wù)，不定時重構(gòu)代碼，不斷構(gòu)造更好的自己。

歡迎各路大神不吝賜教。