工廠模式，從第三方登錄說起-有解無憂

現在的很多平臺在登陸的時候，下面都會有一排選項，可以選擇微信、QQ、微博賬號等登陸，這些賬號對平臺來說都是第三方賬號，第三方賬號登陸是最近幾年流行起來的，第三方賬號登錄一般都是基于OAuth2.0協議開發的，如果你不了解OAuth2.0協議，可以自行百度，也許會對你看這篇文章有所幫助，

現在由于公司要給平臺引入流量，為了降低注冊門檻，讓更多的人來使用你們的平臺，領導決定在你們的平臺上接入第三方賬號登陸功能，現階段先接入微信、支付寶、QQ、GitHub 這四個第三方賬號登陸，這個任務也順利的落到你的頭上，由于你了解OAuth2.0協議，你知道這個是一個固定的三段式操作，第一步獲取Authorization Code，第二步獲取Access Token，第三步呼叫資訊介面，但是每個平臺回傳來的資料欄位或者格式可能會不一樣，所以你根據你的開發經驗，為第三方賬號登錄模塊抽取出來了一個IdentityProvider抽象類，該類主要有上面提到的三步需要的介面，IdentityProvider類的代碼如下：

public abstract class IdentityProvider {

    // 獲取Authorization Code
    abstract void authorizationCode();

    // 獲取 Access Token
    abstract void accessToken();

    // 獲取用戶資訊
    abstract void getUserInfo();
}

每一個第三方賬號平臺都繼承IdentityProvider，根據每個第三方賬號平臺的規則去實作這三個介面，我們已支付寶為例，我們定義一個AliPayIdentityProvider類，該類繼承了IdentityProvider類，AliPayIdentityProvider類代碼如下：


/**
 * 支付寶 第三方登陸具體實作
 */
public class AliPayIdentityProvider extends IdentityProvider{

    private static final String APPID = "你申請的運用id";
    private static final String APPKEY = "你的私鑰";

    public AliPayIdentityProvider() {
        System.out.println("我是支付寶第三方登陸具體實作");
    }

    @Override
    abstract void getUserInfo(){
        // 獲取用戶資訊
    }

    @Override
    public void authorizationCode() {
        //獲取authorization Code
    }

    @Override
    public void accessToken() {
        //獲取access Token
    }
}

四個第三方賬號登錄平臺都按照上面的方式做了具體的實作，除此之外，你還創建了一個IdentityFactory類，該類是創建實體的唯一入口，里面提供了一個靜態create方法,create方法的作用是根據傳入的引數回傳對應的第三方賬號平臺實體，IdentityFactory類代碼如下：

public class IdentityFactory {
    /**
     * 第三方登陸實體獲取
     * @param type 識別符號，1：支付寶登陸 2：微信登陸 3：QQ登錄 4：github登陸 
     */
    public static IdentityProvider create(int type){
        IdentityProvider identityProvider = null;
        switch (type){
            case 1:
                identityProvider = new AliPayIdentityProvider();
                break;
            case 2:
                identityProvider = new WeChatIdentityProvider();
                break;
            case 3:
                identityProvider = new QQIdentityProvider();
                break;
            case 4:
                identityProvider = new GitHubIdentityProvider();
                break;
        }
        return identityProvider;
    }
}

客戶端呼叫時只需要呼叫create()方法即可以獲取對應的實體，比如要使用GitHub賬號登陸，我們只要呼叫IdentityProvider identityProvider = IdentityFactory.create(4);，獲取到GitHub的IdentityProvider，獲取到物件之后，可以進行GitHub賬號登陸的具體操作，提交、部署、測驗、上線，完美完成任務，

在第三方賬號平臺登陸功能的實作中，你使用到了一種設計模式，叫作簡單工廠模式，此時你心里肯定大喊一聲，臥槽，這就用上了設計模式？是的，沒錯，這就是設計模式，既然你好奇，那我們就一起來看看簡單工廠模式，

簡單工廠模式的定義

簡單工廠模式(Simple Factory Pattern)：又稱為靜態工廠方法(Static Factory Method)模式，是創建型模式的一種，在簡單工廠模式中，有一個工廠類來負責其他類的實體創建，這些被創建的實體類都有一個共同的父類，在我們的第三方賬號登陸中AliPayIdentityProvider、WeChatIdentityProvider都是被實體化的類，它們都有一個共同的父類IdentityProvider，在簡單工廠模式中，工廠類中可以根據傳入的引數回傳不同的實體，在我們的IdentityFactory類中，我們提供了一個靜態的create(int type)，可以根據傳入的型別回傳不同的實體，所以我們這個是標準的簡單工廠模式的實體，

上面這一大段不好理解？沒關系，那我們在抽象一下，簡單工廠模式主要有以下三個成員：

抽象產品：抽象產品角色是所創建的所有物件的父類，負責描述所有實體所共有的公共介面，例如IdentityProvider
具體產品：具體產品角色是創建目標，所有創建的物件都充當這個角色的某個具體類的實體，例如AliPayIdentityProvider
工廠類：負責實作創建所有實體的內部邏輯，例如IdentityFactory

我們再來看一下簡單工廠模式的UML圖：

這些該明白簡單工廠模式了吧，雖然名字中帶有簡單兩個字，但是按照常理來說，就算再簡單，也該會有一些優點吧，既然你還好奇，那就繼續來簡單工廠模式有哪些優點吧，

簡單工廠模式的優點

工廠類含有必要的判斷邏輯，可以決定在什么時候創建哪一個產品類的實體，客戶端可以免除直接創建產品物件的責任，而僅僅“消費”產品；簡單工廠模式通過這種做法實作了對責任的分割，它提供了專門的工廠類用于創建物件，
客戶端無須知道所創建的具體產品類的類名，只需要知道具體產品類所對應的引數即可，對于一些復雜的類名，通過簡單工廠模式可以減少使用者的記憶量，
通過引入組態檔，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產品類，在一定程度上提高了系統的靈活性，

第三方賬號登陸功能上線后，你們公司平臺的用戶急速增強，boss甚是高興，于是又給你安排活來了，這次boss叫你把微博賬號登陸加上，實作使用微博賬號登陸到你們的平臺，有了前面的經驗之后，這事對你來說太簡單的，你給系統新增了一個WeiBoIdentityProvider類，用來實作微博賬號登錄，WeiBoIdentityProvider類如下：


/**
 * 微博賬號登陸
 */
public class WeiBoIdentityProvider extends IdentityProvider{

    private static final String APPID = "你申請的運用id";
    private static final String APPKEY = "你的私鑰";

    public WeiBoIdentityProvider() {
        System.out.println("我是微博第三方登陸具體實作");
    }

    @Override
    abstract void getUserInfo(){
        // 獲取用戶資訊
    }

    @Override
    public void authorizationCode() {
        //
    }

    @Override
    public void accessToken() {

    }
}

在IdentityFactory類中添加了case 5分支，用來回傳微博賬號登陸實體，變更之后IdentityFactory類如下：：

public class IdentityFactory {
    /**
     * 第三方登陸驗證
     * @param type 識別符號，1：支付寶登陸 2：微信登陸 3：QQ登錄 4：github登陸 5：微博賬號
     */
    public static IdentityProvider crete(int type){
        IdentityProvider identityProvider = null;
        switch (type){
            case 1:
                identityProvider = new AliPayIdentityProvider();
                break;
            case 2:
                identityProvider = new WeChatIdentityProvider();
                break;
            case 3:
                identityProvider = new QQIdentityProvider();
                break;
            case 4:
                identityProvider = new GitHubIdentityProvider();
            case 5:
                identityProvider = new WeiBoIdentityProvider();
                break;
        }
        return identityProvider;
    }
}

部署、測驗微博賬號登陸，沒有問題，打包上線，關機下班，上線之后，大量用戶反饋GitHub賬號登陸不上，小伙子，出來接鍋了，于是你又要屁顛屁顛的跑回公司加班改 bug ，苦逼的程式員，你找呀找呀，最后發現了，case 4的break陳述句被你刪掉了，所以在使用GitHub賬號登陸時，IdentityFactory工廠回傳的實體一直都是WeiBoIdentityProvider，導致GitHub賬號登陸會失敗，不經意間的一個小失誤，造成了一次線上事故，生產上都出事了，后果你懂的，雖然這事故是你人為造成的，但這也是簡單工廠模式的缺點，你每新增第三方賬號登入平臺時，都需要去改動工廠類，這難免會出現這種誤刪的情況，簡單工廠模式雖然簡單，但是也有不少缺點，那我們一起看看簡單工廠模式有哪些缺點吧，

簡單工廠模式的缺點

違背“開放 - 關閉原則”，一旦添加新產品就不得不修改工廠類的邏輯，這樣就容易造成錯誤，就像我們上面那樣，一不小心造成線上事故
工廠類集中了所有實體（產品）的創建邏輯，一旦這個工廠不能正常作業，整個系統都會受到影響
簡單工廠模式由于使用了靜態工廠方法，造成工廠角色無法形成基于繼承的等級結構，

經過了這次事故之后，你一心想證明自己，重新獲得領導的賞識，你下定決心要對第三方賬號登陸模塊進行重構，老話說的好：在哪里跌倒就要在哪里爬起來，于是你想呀想呀，最后靈光一現，需要對IdentityFactory類進行重構，工廠類也需要像提供方一樣，提取出一個抽象類，然后每個提供方有自己的工廠，這樣就可以避免新增時對原有系統模塊的改動，于是你抽象出來一個IdentityProviderFactory類，用來定義工廠需要的介面，IdentityProviderFactory類如下：

/**
 * 第三方登陸抽象工廠
 */
public abstract class IdentityProviderFactory<T> {
    // 創建具體的IdentityProvider
    public abstract IdentityProvider create();
}

每個第三方賬號平臺都需要有自己的生產工廠，這個工廠必須繼承IdentityProviderFactory類，然后重寫create()方法，在create()方法里實體化自己的identityProvider實作類，我們以支付寶工廠為例，我們需要創建一個AliPayIdentityProviderFactory類,AliPayIdentityProviderFactory類代碼如下：

/**
 * 支付寶第三方登陸工廠類
 */
public class AliPayIdentityProviderFactory extends IdentityProviderFactory<AliPayIdentityProvider> {
    @Override
    public IdentityProvider create() {
        //支付寶登錄實作實體
        return new AliPayIdentityProvider();
    }
}

在create()方法中回傳AliPayIdentityProvider實體，每個工廠都回傳對應的實體就可以，客戶端在呼叫時，也要發生相應的改變，不在傳入引數來獲取實體，而是通過呼叫對應的工廠來獲取實體，比如我們使用支付寶賬號登陸

// 呼叫支付寶工廠
IdentityProviderFactory providerFactory  = new AliPayIdentityProviderFactory();
// 獲取IdentityProvider
IdentityProvider provider = providerFactory.create();
// 一些列第三方認證操作

重構之后，我們肯定不會再出現上一次的問題，因為現在每個第三方賬號提供方都有自己的工廠，每個產品的構建運行都是獨立的，小伙子，恭喜你，你離升職加薪不遠了，

在你重構的程序中，你也將簡單工廠模式進行了升級，現在它不叫簡單工廠模式了，因為它已經不簡單了，現在的模式叫作工廠方法模式(Factory Method Pattern)，既然我們都用上了工廠方法模式，那就不妨一起來了解一下工廠方法模式吧，

工廠方法模式的定義

工廠方法模式(Factory Method Pattern)又稱為工廠模式，也叫虛擬構造器(Virtual Constructor)模式或者多型工廠(Polymorphic Factory)模式，它也是類創建型模式的一種，工廠方法模式與簡單工廠模式的區別在于，在工廠方法模式中，實體的創建不是集中在一個工廠中，而是抽取出來了一個工廠父類，工廠父類負責定義創建產品物件的公共介面，而工廠子類則負責生成具體的產品物件，這樣做的目的是將產品類的實體化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應該實體化哪一個具體產品類，就像我們的IdentityProviderFactory類和AliPayIdentityProviderFactory類，

跟簡單工廠模式一樣，我們對工廠方法模式也進行抽象一下，工廠方法模式有下面四個成員：

抽象產品：定義好產品具有的屬性方法，例如IdentityProvider
具體產品：具體的產品實作，例如AliPayIdentityProvider
抽象工廠：定義好工廠的抽象方法，例如IdentityProviderFactory
具體工廠：具體的生產工廠，例如AliPayIdentityProviderFactory

老慣例，一起看看工廠方法模式的UML圖，加深印象：

工廠方法模式好處在我們重構第三方賬號登錄模塊的時候，我們已經體驗到了，工廠方法模式的好處可不止那么一點，一起來看看工廠方法模式有哪些優點？

工廠方法模式的優點

工廠方法模式的擴展性非常強，在系統中加入新產品時，無須修改抽象工廠和抽象產品提供的介面，而只要添加一個具體工廠和具體產品，就可以擁抱變化，就像如果我們現在要接入釘釘賬號登陸，我們只需要創建DingDingIdentityProviderFactory和DingDingIdentityProvider就好了
良好的封裝性，代碼結構清晰，呼叫者需要一個具體的產品物件時，只需要知道這個產品的類名就可以了，不需要知道具體的創建程序，降低的模塊之間的耦合
屏蔽產品類，產品類的實作如何變化，呼叫者不需要關系，它只關系產品的介面，只要介面保持不變，系統中的上層模塊就不需要變化，所以工廠方法模式經常用來解耦，高層模塊只需要知道產品的抽象類，實作類不需要關系，這符合迪米特法則，也符合依賴倒置原則，

工廠方法模式雖然有諸多好處，但是它也有不少缺點，因為不可能有完美無缺的設計模式，那我們一起來看看工廠方法模式的缺點，

工廠方法模式的缺點

增加了系統復雜度，我們將工廠類拆分出來，無形之中給我們的系統帶來了復雜性
增加了開發量，在使用簡單工廠模式時，我們只想要添加一個case分支，現在則需要創建類
由于考慮到系統的可擴展性，需要引入抽象層，在客戶端代碼中均使用抽象層進行定義，增加了系統的抽象性和理解難度，且在實作時可能需要用到DOM、反射等技術，增加了系統的實作難度

總結

本文主要簡單的介紹了一下簡單工廠模式和工廠方法模式這兩種設計模式，通過第三方賬號登陸這個案例，從簡單工廠模式開始，一步一步的到了工廠方法模式，想要更深入的了解工廠模式，需要參考大量的案例，spring等開源框架中應用了大量的設計模式，工廠模式自然少不了，不管學習哪種設計模式，我們都可以去參考這些開源框架，它能夠加深你對設計模式的理解，

源代碼

文章不足之處，望大家多多指點，共同學習，共同進步

最后

打個小廣告，歡迎掃碼關注微信公眾號：「平頭哥的技術博文」，一起進步吧，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/46470.html

標籤：設計模式

上一篇：觀察者模式

下一篇：模板方法模式