第35章　工廠方法模式+策略模式 35.1 迷你版的交易系統 大家可能對銀行的交易系統充滿敬畏之情，一聽說是銀行的IT人員，立馬想當然地認為這是個很厲害的人物，那我們今天就來對銀行的交易系統做一個初步探討。國內一家大型集團（全球500強之一）計劃建立全國“一卡通”計劃，每個員工配備一張IC卡，該卡基本上就是萬能的，門禁系統用它，辦公系統用它，你想打開自己的郵箱，沒有它就甭想了，它還可以用來進行消費，比如到食堂吃飯，到園區內的商店消費，甚至洗澡、理發、借書、買書等都可以用它，只要這張卡內有余額，在集團內部就是一張借記卡（當然還有一些內部的補助通過該卡發放）。我們要講解的就是“一卡通”項目聯機交易子系統，類似于銀行的交易系統，可以說它是交易系統的mini版吧。 該項目具有一定的挑戰性，集團公司的架構分為三層：總部、省級分部、市級機構，業務要求是“一卡通”推廣到全國，一名員工從北京出差到了上海，憑一卡通能在北京做的事情在上海同樣能完成。對于聯機交易子項目，異地分支機構與總部之間的通信采用了MQ（Message Queue，消息隊列）傳遞消息，也就是我們觀察者模式的BOSS版，與目前的通過POS機刷信用卡基本上是一個道理。 聯機交易子系統有一個非常重要的子模塊（Module）——扣款子模塊。這個模塊太重要了！從業務上來說，扣款失敗就代表著所有的商業交易關閉，這是不允許發生的；從技術上來說，扣款的異常處理、事務處理、魯棒性都是不容忽視的，特別是飯點時間，并發量是很恐怖的，這對架構師提出了很高的要求。 我們詳細分析一下扣款子模塊，每個員工都有一張IC卡，他的IC卡上有以下兩種金額。 ● 固定金額 固定金額是指員工不能提現的金額，這部分金額只能用來特定消費，即員工日常必需的消費，例如食堂內吃飯、理發、健身等活動。 ● 自由金額 自由金額是可以提現的，當然也可以用于消費。每個月初，總部都會為每個員工的IC卡中打入固定數量的金額，然后提倡大家在集團內的商店消費。 在實際的系統開發中，架構設計采用的是一張IC卡綁定兩個賬戶：固定賬戶和自由賬號，本書為了簡化描述，還是使用固定金額和自由金額的概念。既然有消費，系統肯定有扣款處理，系統內有兩套扣款規則。 ● 扣款策略一 該類型的扣款會對IC卡上的兩個金額產生影響，計算公式如下： IC卡固定余額=IC卡現有固定余額-交易金額/2 IC卡自由余額=IC卡現有自由金額-交易金額/2 也就是說，該類型的消費分別在固定金額和自由金額上各扣除一半。它適用于固定消費場景例如吃飯、理發等情況下的扣款，這么做是為了防止亂請客，你請別人吃飯時自己也要出一半。 ● 扣款策略二 全部從自由金額上扣除，由于集團內的各種消費、服務非常齊全，而且比市面價格稍低，員工還是很樂意到這里消費的，而且很多員工本身就住在集團附近，基本上就是“公司即家，家即公司”。 今天要講的重點就是這兩種消費的扣款策略該怎樣設計？要知道這種聯機交易，日后允許大規模變更的可能性基本上是零，所以系統設計的時候要做到可拆卸（Pluggable），避免日后維護的大量開支。 很明顯，這是一個策略模式的實際應用，但是你還記得策略模式是有缺陷的嗎？它的具體策略必須暴露出去，而且還要由上層模塊初始化，這不合適，與迪米特法則有沖突，高層次模塊對低層次的模塊應該僅僅處在“接觸”的層次上，而不應該是“耦合”的關系，否則，維護的工作量就會非常大。問題提出了，那我們就應該想辦法來修改這個缺陷，正好工廠方法模式可以幫我們產生指定的對象，但是問題又來了，工廠方法模式要指定一個類，它才能產生對象，怎么辦？引入一個配置文件進行映射，避免系統僵化情況的發生，我們以枚舉類完成該任務。 還有一個問題，一個交易的扣款模式是固定的，根據其交易編號而定，那我們怎樣把交易編號與扣款策略對應起來呢？采用狀態模式或責任鏈模式都可以，如果采用狀態則認為交易編號就是一個交易對象的狀態，對于一筆確定的交易（一個已經生成了的對象），它的狀態不會從一個狀態過渡到另一個狀態，也就是說它的狀態只有一個，執行完畢后即結束，不存在多狀態的問題；如果采用責任鏈模式，則可以用交易編碼作為鏈中的判斷依據，由每個執行節點進行判斷，返回相應的扣款模式。但是在實際中，采用了關系型數據庫存儲扣款規則與交易編碼的對應關系，為了簡化該部分的講義，我們在下面的設計中使用了條件判斷語句來代替。 還有，這么復雜的扣款模塊總要進行一個封裝吧，不能讓上層的業務模塊直接深入到模塊的內部，于是門面模式又擺在了眼前。 分析完畢，我們要先畫出類圖，做設計要遵循這樣一個原則：先選最簡單的業務，然后畫出類圖。那我們先定義交易中用到的兩個類：IC卡類和交易類，如圖35-1所示。  圖35-1 IC卡類和交易類 每個IC卡有三個屬性，分別是IC卡號碼、固定金額、自由金額，然后通過getter/setter方法來訪問，如代碼清單35-1所示。 代碼清單35-1 IC卡類 public?class?Card?{ ?????//IC卡號碼 ?????private?String?cardNo=""; ?????//卡內的固定交易金額 ?????private?int?steadyMoney?=0; ?????//卡內自由交易金額 ?????private?int?freeMoney?=0; ?????//getter/setter方法????? ?????public?String?getCardNo()?{ ?????????????return?cardNo; ?????} ?????public?void?setCardNo(String?cardNo)?{ ?????????????this.cardNo?=?cardNo; ?????} ?????public?int?getSteadyMoney()?{ ?????????????return?steadyMoney; ?????} ?????public?void?setSteadyMoney(int?steadyMoney)?{ ?????????????this.steadyMoney?=?steadyMoney; ?????} ?????public?int?getFreeMoney()?{ ?????????????return?freeMoney; ?????} ?????public?void?setFreeMoney(int?freeMoney)?{ ?????????????this.freeMoney?=?freeMoney; ?????} } 細心的讀者可能注意到，金額怎么都是整數類型呀，應該是double類型或者BigDecimal類型呀。是，一般非銀行的交易系統，比如超市的收銀系統，系統內都是存放的int類型，在顯示的時候才轉換為貨幣類型。 交易信息Trade類，負責記錄每一筆交易，它是由監聽程序監聽MQ隊列而產生的，有兩個屬性：交易編號和交易金額，其中的交易編號對整個交易非常重要，18位字符（在銀行的交易系統中，這里可不是字符串，一般是十進制數字或二進制數字，要考慮系統的性能，數字運算可比字符運算快得多），包括POS機編號、商戶編號、校驗碼等，我們這里暫時用不到，就不多做介紹，我們只要知道它是一個非常有用的編碼就成。交易金額為整數類型，實際金額放大100倍即可。如代碼清單35-2所示。 代碼清單35-2 交易類 public?class?Trade?{ ?????//交易編號 ?????private?String?tradeNo?=?""; ?????//交易金額 ?????private?int?amount?=?0; ?????//getter/setter方法 ?????public?String?getTradeNo()?{ ?????????????return?tradeNo; ?????} ?????public?void?setTradeNo(String?postNo)?{ ?????????????this.tradeNo?=?postNo; ?????} ?????public?int?getAmount()?{ ?????????????return?amount; ?????} ?????public?void?setAmount(int?amount)?{ ?????????????this.amount?=?amount; ?????} } 兩個最簡單也是在應用中最常使用的對象定義完畢，下面就需要來定義策略了，非常明顯的策略模式，類圖如圖35-2所示。 典型的策略模式，扣款有兩種策略：固定扣款和自由扣款。下面我們來看代碼，先看抽象策略，也就是扣款接口，如代碼清單35-3所示。 代碼清單35-3 扣款策略接口 public?interface?IDeduction?{ ?????//扣款，提供交易和卡信息，進行扣款，并返回扣款是否成功 ?????public?boolean?exec(Card?card,Trade?trade); } 固定扣款的規則是固定金額和自由金額各扣除交易金額的一半，如代碼清單35-4所示。 代碼清單35-4 扣款策略一 public?class?SteadyDeduction?implements?IDeduction?{ ?????//固定性交易扣款 ?????public?boolean?exec(Card?card,?Trade?trade)?{ ?????????????//固定金額和自由金額各扣除50% ?????????????int?halfMoney?=?(int)Math.rint(trade.getAmount()?/?2.0); ?????????????card.setFreeMoney(card.getFreeMoney()?-?halfMoney); ?????????????card.setSteadyMoney(card.getSteadyMoney()?-?halfMoney); ?????????????return?true; ?????} }  圖35-2 扣款策略類圖 這個具體策略也非常簡單，就是兩個金額各自減去交易額的一半（注意除數是2.0，可不是2），然后再四舍五入，算法確實簡單。該邏輯沒有考慮賬戶余額不足的情況，也沒有考慮異常情況，比如并發情況，讀者可以想想看，一張卡有兩筆消費同時發生時，是不是就發生錯誤了？一張卡同時有兩筆消費會出現這種情況嗎？會的，網絡阻塞的情況，MQ多通道發送，在網絡繁忙的情況下是有可能出現該問題，這里就不多介紹，有興趣的讀者可以看看MQ的資料。我們在這里的講解實現的是一個快樂路徑，認為所有的交易都是在安全可靠的環境中發生的，并且所有的系統環境都滿足我們的要求。我們再來看另一個策略，這個策略更簡單，如代碼清單35-5所示。 代碼清單35-5 扣款策略二 public?class?FreeDeduction?implements?IDeduction?{ ?????//自由扣款 ?????public?boolean?exec(Card?card,?Trade?trade)?{ ?????????????//直接從自由余額中扣除 ?????????????card.setFreeMoney(card.getFreeMoney()?-?trade.getAmount()); ?????????????return?true; ?????} } 卡內的自由金額減去交易金額再修改卡內自由金額就完事了，異常情況不考慮。這兩個具體的策略與我們的交易類型沒有任何關系，也不應該有關系，策略模式就是提供兩個可以相互替換的策略，至于在什么時候使用什么策略，則不是由策略模式來決定的。策略模式還有一個角色沒出場，即封裝角色，如代碼清單35-6所示。 代碼清單35-6 扣款策略的封裝 public?class?DeductionContext?{ ?????//扣款策略 ?????private?IDeduction?deduction?=?null; ?????//構造函數傳遞策略 ?????public?DeductionContext(IDeduction?_deduction){ ?????????????this.deduction?=?_deduction; ?????} ?????//執行扣款 ?????public?boolean?exec(Card?card,Trade?trade){ ?????????????return?this.deduction.exec(card,?trade); ?????} } 典型的策略上下文角色。扣款模塊的策略已經定義完畢了，然后需要想辦法解決策略模式的缺陷：它把所有的策略類都暴露出去，暴露得越多以后的修改風險也就越大。怎么修改呢？增加一個映射配置文件，實現策略類的隱藏。我們使用枚舉擔當此任，對策略類進行映射處理，避免高層模塊直接訪問策略類，同時由工廠方法模式根據映射產生策略對象，類圖如圖35-3所示。  圖35-3 策略工廠類圖 又是一個簡單得不能再簡單的模式——工廠方法模式，通過StrategyMan負責對具體策略的映射，如代碼清單35-7所示。 代碼清單35-7 策略枚舉 public?enum?StrategyMan?{ ?????SteadyDeduction("com.cbf4life.common.SteadyDeduction"), ?????FreeDeduction("com.cbf4life.common.FreeDeduction"); ?????String?value?=?""; ?????private?StrategyMan(String?_value){ ?????????????this.value?=?_value; ?????} ?????public?String?getValue(){ ?????????????return?this.value; ?????} } 類似的代碼解釋過很多遍了，不再多說，它就是一個登記容器，所有的具體策略都在這里登記，然后提供給工廠方法模式。策略工廠如代碼清單35-8所示。 代碼清單35-8 策略工廠 public?class?StrategyFactory?{ ?????//策略工廠 ?????public?static?IDeduction?getDeduction(StrategyMan?strategy){ ?????????????IDeduction?deduction?=?null; ?????????????try?{ ??????????????????deduction?=?(IDeduction)Class.forName(strategy.getValue()).newInstance(); ?????????????}??catch?(Exception?e)?{ ?????????????????????//?異常處理 ?????????????} ?????????????return?deduction; ?????} } 一個簡單的工廠，根據策略管理類的枚舉項創建一個策略對象，簡單而實用，策略模式的缺陷也彌補成功。那這么復雜的系統怎么讓高層模塊訪問？（你看不出復雜？那是因為我們寫的都是快樂路徑，太多情況都沒有考慮，在實際項目中僅就并發處理和事務管理這兩部分就夠你頭疼了。）既然系統很復雜，是不是需要封裝一下。我們請出門面模式進行封裝，如代碼清單35-9所示。 代碼清單35-9 扣款模塊封裝 public?class?DeductionFacade?{ ?????//對外公布的扣款信息 ?????public?static?Card?deduct(Card?card,Trade?trade){ ?????????????//獲得消費策略 ?????????????StrategyMan?reg?=?getDeductionType(trade); ?????????????//初始化一個消費策略對象 ?????????????IDeduction?deduction?=?StrategyFactory.getDeduction(reg); ?????????????//產生一個策略上下文 ?????????????DeductionContext?context?=?new?DeductionContext(deduction); ?????????????//進行扣款處理 ?????????????context.exec(card,?trade); ?????????????//返回扣款處理完畢后的數據 ?????????????return?card; ?????} ?????//獲得對應的商戶消費策略 ?????private?static?StrategyMan?getDeductionType(Trade?trade){ ?????????????//模擬操作 ?????????????if(trade.getTradeNo().contains("abc")){ ?????????????????????return?StrategyMan.FreeDeduction; ?????????????}else{ ?????????????????????return?StrategyMan.SteadyDeduction; ?????????????} ?????} } 這次為什么要先展示代碼而后寫類圖呢？那是因為這段代碼比寫類圖更能讓你理解。讀者注意一下getDeductionType方法，這個方法在實際項目中是存在的，但是與上面的寫法有天壤之別，因為在實際項目中，數據庫中保存了策略代碼與交易編碼的對應關系，直接通過數據庫的SQL語句就可以返回對應的扣款策略。這里我們采用大家最熟悉的條件轉移來實現，也是比較清晰和容易理解的。 可能讀者要問了，在門面模式中已經明確地說明，門面類中不允許有業務邏輯存在，但是你這里還是有了一個getDeductionType方法，它可代表的是一個判斷邏輯呀，這是為什么呢？是的，該方法完全可以移到其他Hepler類中，由于我們是示例代碼，暫沒有明確的業務含義，故編寫在此處，讀者在實際應用中，請把該方法放置到其他類中。 好，所有用到的模式都介紹完畢了，我們把完整的類圖整理一下，如圖35-4所示。  圖35-4 扣款子模塊完整類圖 真實系統比這復雜得多，有了我們之前的分析，這個圖還是比較容易看懂的。我們所有的開發都完成了，是不是應該寫一個測試類來展示一下我們的成果，如代碼清單35-10所示。 代碼清單35-10 場景類 public?class?Client?{ ?????//模擬交易 ?????public?static?void?main(String[]?args)?{ ?????????????//初始化一張IC卡 ?????????????Card?card?=?initIC(); ?????????????//顯示一下卡內信息 ?????????????System.out.println("========初始卡信息：========="); ?????????????showCard(card);????? ?????????????//是否停止運行標志 ?????????????boolean?flag?=?true; ?????????????while(flag){ ?????????????????????Trade?trade?=?createTrade(); ?????????????????????DeductionFacade.deduct(card,?trade); ?????????????????????//交易成功，打印出成功處理消息 ?????????????????????System.out.println("\n======交易憑證========"); ?????????????????????System.out.println(trade.getTradeNo()+"?交易成功！"); ?????????????????????System.out.println("本次發生的交易金額為："+? ????????????????????????trade.getAmount()/100.0+"元"); ?????????????????????//展示一下卡內信息 ?????????????????????showCard(card); ?????????????????????System.out.print("\n是否需要退出？(Y/N)"); ?????????????????????if(getInput().equalsIgnoreCase("y")){ ?????????????????????????????flag?=?false;??//退出 ?????????????????????} ?????????????} ?????} ?????//初始化一個IC卡 ?????private?static?Card?initIC(){ ?????????????Card?card?=?new?Card(); ?????????????card.setCardNo("1100010001000"); ?????????????card.setFreeMoney(100000);??//1000元 ?????????????card.setSteadyMoney(80000);?//800元 ?????????????return?card; ?????} ?????//產生一條交易 ?????private?static?Trade?createTrade(){ ?????????????Trade?trade?=?new?Trade(); ?????????????System.out.print("請輸入交易編號："); ?????????????trade.setTradeNo(getInput()); ?????????????System.out.print("請輸入交易金額："); ?????????????trade.setAmount(Integer.parseInt(getInput())); ?????????????//返回交易 ?????????????return?trade; ?????} ?????//打印出當前卡內交易余額 ?????public?static?void?showCard(Card?card){ ?????????????System.out.println("IC卡編號:"?+?card.getCardNo()); ?????????????System.out.println("固定類型余額："+?card.getSteadyMoney()/100.0?+?"?元"); ?????????????System.out.println("自由類型余額："+?card.getFreeMoney()/100.0?+?"?元"); ?????} ?????//獲得鍵盤輸入 ?????public?static?String?getInput(){ ?????????????String?str?=""; ?????????????try?{ ???????????????????str=(new?BufferedReader(new?InputStreamReader(System.in))).readLine(); ?????????????}?catch?(IOException?e)?{ ??????????????????//異常處理 ?????????????} ?????????????return?str; ?????} } 類比較長，耐心看還是非常簡單的，對其中Client類的方法說明如下： ● initIC方法 初始化一張IC卡，方便進行測試。 ● createTrade方法 創建一筆交易，完成測試任務。 ● showCard方法 顯示IC卡內的信息。 ● getInput方法 獲得從鍵盤輸入的字符，以回車符作為終結標志。 方法介紹完畢了，我們運行一下看看，結果如下所示： ========初始卡信息：========= IC卡編號:1100010001000 固定類型余額：800.0 元 自由類型余額：1000.0 元 請輸入交易編號：abcdef 請輸入交易金額：10000 ======交易憑證======== abcdef 交易成功！ 本次發生的交易金額為：100.0 元 IC卡編號:1100010001000 固定類型余額：800.0 元 自由類型余額：900.0 元 是否需要退出？(Y/N) 我們模擬了一筆自由消費，直接從自由類型金額中扣除了。我們再模擬一筆固定類型的消費，運行結果如下所示： ========初始卡信息：========= IC卡編號:1100010001000 固定類型余額：800.0 元 自由類型余額：1000.0 元 請輸入交易編號：abcdef 請輸入交易金額：10000 ======交易憑證======== abcdef 交易成功！ 本次發生的交易金額為：100.0 元 IC卡編號:1100010001000 固定類型余額：800.0 元 自由類型余額：900.0 元 是否需要退出？(Y/N)n 請輸入交易編號：1001 請輸入交易金額：1234 ======交易憑證======== 1001 交易成功！ 本次發生的交易金額為：12.34 元 IC卡編號:1100010001000 固定類型余額：793.83 元 自由類型余額：893.83 元 是否需要退出？(Y/N) 交易成功！到這里為止，聯機交易中的扣款子模塊開發完畢了！是不是很簡單，銀行業的交易系統也就是這么回事！