工廠模式，從第三方登錄說起
- 2019 年 10 月 3 日
- 筆記
現在的很多平台在登陸的時候，下面都會有一排選項，可以選擇微信、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等開源框架中應用了大量的設計模式，工廠模式自然少不了，不管學習哪種設計模式，我們都可以去參考這些開源框架，它能夠加深你對設計模式的理解。
文章不足之處，望大家多多指點，共同學習，共同進步
最後
打個小廣告，歡迎掃碼關注微信公眾號：「平頭哥的技術博文」，一起進步吧。