最近在忙着項目，剛好自己用到了工廠模式，然後就去找了相關的文章，這篇文章着實寫的接地氣。
轉載地址：https://blog.csdn.net/z694644032/article/details/100940148
現在的很多平臺在登陸的時候，下面都會有一排選項，可以選擇微信、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等開源框架中應用了大量的設計模式，工廠模式自然少不了，不管學習哪種設計模式，我們都可以去參考這些開源框架，它能夠加深你對設計模式的理解。