現在的很多平臺在登陸的時候，下面都會有一排選項，可以選擇微信、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等開源框架中應用了大量的設計模式，工廠模式自然少不了，不管學習哪種設計模式，我們都可以去參考這些開源框架，它能夠加深你對設計模式的理解。

原始碼

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

最後

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

相關推薦