QA系統學習記錄
大咖揭祕Java人都栽在了哪？點選免費領取《大廠面試清單》，攻克面試難關~>>>
▐模式定義
▐適用場景
適用於多節點的流程處理，每個節點完成各自負責的部分，節點之間不知道彼此的存在，比如 OA 的審批流，Java Web 開發中的 Filter 機制。
多個物件可以處理同一個請求，但具體由哪個物件處理則在執行時動態決定。
在請求處理者不明確的情況下向對個物件中的一個提交一個請求。
需要動態處理一組物件處理請求。
舉一個生活中的例子，比如你突然想世界那麼大你想去看看，但是處於現實的你還不能丟了工作，得到請假的OA申請，請假天數如果是半天到1天，可能直接主管批准即可；如果是1到3天的假期，需要部門經理批准；如果是3天到30天，則需要總經理審批；大於30天，正常不會批准。這種簡單的流程即可試用於我們當前業務場景。
▐實踐經驗
業務流程很簡單：
打電話登出信用卡
工作人員登出信用卡
登出信用卡有個背景是這樣的，如果信用卡存在賬單未還清，存在溢位款，存在特殊年費未使用等情況是不允許登出信用卡的，鑑於此，我們在登出之前加了一套是否允許登出的檢驗邏輯。
大體如下：
是否存在賬單未還清，比如有已出賬單未還清，有未出賬單未還清，有年費管理費等未還清等。
是否存在溢位款多餘的錢。
是否存在高額積分未使用，需使用者確認放棄積分等。
針對這幾類情況建立了三類過濾器，分別是：
UserLogoutUnpaidBillsLimitFilter：是否存在未還清金額。
UserLogoutOverflowLimitFilter：是否存在溢位款。
UserLogoutGiveUpPointsLimitFilter：是否放棄高額金額。
判斷邏輯是先通過UserLogoutUnpaidBillsLimitFilter判斷當前使用者是否可以登出信用卡。如果允許繼續由 UserLogoutOverflowLimitFilter 判斷是否存在溢位款，是否可以登出信用卡；如果沒有溢位款繼續由UserLogoutGiveUpPointsLimitFilter 判斷當前使用者是否存在高額積分，前面三條判斷，只要有一個不滿足就提前返回。
public boolean canLogout(String userId) {//獲取使用者資訊UserInfo userInfo = getUserInfo(userId);// 構造登出信用卡限制過濾器鏈條LogoutLimitFilterChain filterChain = new LogoutLimitFilterChain();filterChain.addFilter(new UserLogoutUnpaidBillsLimitFilter());filterChain.addFilter(new UserLogoutOverflowLimitFilter());filterChain.addFilter(new UserLogoutGiveUpPointsLimitFilter());boolean checkResult = filterChain.doFilter(filterChain, userInfo);//filterChain.doFilter方法public boolean doFilter (LogoutLimitFilterChain filterChain, UserInfo userInfo){//迭代呼叫過濾器if (index < filters.size()) {return filters.get(index++).doFilter(filterChain, userInfo);}}}//UserLogoutUnpaidBillsLimitFilter.doFilter方法public boolean doFilter(LogoutLimitFilterChain filterChain, UserInfo userInfo) {//獲取使用者當前欠款金額UserCardBillInfo userCardBillInfo = findUserCardBillInfo(userInfo);// 判斷當前卡使用者是否允許消費if (userCardBillInfo != null) {if ((!CAN_LOGOUT.equals(userCardBillInfo.getEnabledLogout()))) {return false;}}//其餘情況，繼續往後傳遞return filterChain.doFilter(filterChain, memberInfo, consumeConfig);}//UserLogoutOverflowLimitFilter.doFilter方法public boolean doFilter(LogoutLimitFilterChain filterChain, UserInfo userInfo) {//判斷使用者是否存在溢位款UserCardDeposit userCardDeposit = findUserCardDeposit(userInfo);// 判斷當前卡使用者是否允許消費if (userCardDeposit != null) {if (userCardDeposit.getDeposit() != 0) {return false;}}//其餘情況，繼續往後傳遞return filterChain.doFilter(filterChain, memberInfo, consumeConfig);}
總結：將每種限制條件的判斷邏輯封裝到了具體的 Filter 中，如果某種限制條件的邏輯有修改不會影響其他條件，如果需要新加限制條件只需要重新構造一個 Filter 織入到 FilterChain 上即可。
責任鏈中一個處理者物件，其中只有兩個行為，一是處理請求，二是將請求轉送給下一個節點，不允許某個處理者物件在處理了請求後又將請求轉送給上一個節點的情況。對於一條責任鏈來說，一個請求最終只有兩種情況，一是被某個處理物件所處理，另一個是所有物件均未對其處理，前一種情況稱該責任鏈為純的責任鏈，對於後一種情況稱為不純的責任鏈，實際應用中，多為不純的責任鏈。
策略設計模式
▐模式定義
策略這個詞應該怎麼理解，打個比方說，我們出門的時候會選擇不同的出行方式，比如騎自行車、坐公交、坐火車、坐飛機等等，這些出行方式，每一種都是一個策略。
再比如我們去逛商場，商場現在正在搞活動，有打折的、有滿減的、有返利的等等，其實不管商場如何進行促銷，說到底都是一些演算法，這些演算法本身只是一種策略，並且這些演算法是隨時都可能互相替換的，比如針對同一件商品，今天打八折、明天滿100減30，這些策略間是可以互換的。
策略模式（Strategy Pattern）是定義了一組演算法，將每個演算法都封裝起來，並且使它們之間可以互換。
▐適用場景
主要是為了消除大量的 if else 程式碼，將每種判斷背後的演算法邏輯提取到具體的策略物件中，當演算法邏輯修改時對使用者無感知，只需要修改策略物件內部邏輯即可。這類策略物件一般都實現了某個共同的介面，可以達到互換的目的。
多個類只有演算法或行為上稍有不同的場景
演算法需要自由切換的場景
需要遮蔽演算法規則的場景
▐實踐經驗
業務流程很簡單：
挑選商品
選擇不同的優惠方式結賬
比如即將到來的雙十一活動某些線下商家舉辦活動，折扣力度如下滿300-80，部分商品5折，根據不同會員等級享受不同的折扣最低7折，週年慶活動可享8折等等。假如這些活動折扣不可同享，那麼如何去實現以及考慮可擴充套件性的話策略模式是一種不錯的選擇。
/*** 抽象折扣策略介面*/public abstract class DiscountStrategy {/*** 計算折扣後的價格* @param price 原價* @return 折扣後的價格*/public abstract CalculationResult getDiscountPrice(Long userId ,BigDecimal price);}/*** 滿減活動 -- 滿300減80*/public class FullReductionStrategyOne extends DiscountStrategy {/*** 計算折扣後的價格* @param price 原價* @return*/@Overridepublic CalculationResult getDiscountPrice(Long userId ,BigDecimal price) {if (price.doubleValue() < 300) {return price;}BigDecimal dealPrice= price.subtract(BigDecimal.valueOf(80));return getCalculationResult(userId,dealPrice);}}/*** 部分商品5折*/public class MerchandiseDiscountStrategy extends DiscountStrategy {/*** 計算折扣後的價格* @param price 原價* @return*/@Overridepublic CalculationResult getDiscountPrice(BigDecimal price) {BigDecimal dealPrice= price.multiply(BigDecimal.valueOf(0.5));return getCalculationResult(userId,dealPrice);}}/***當有新的需求式，我們只需要新增一個新的介面即可，不需要修改原有的具體策略實現程式碼即可完成。*定義完策略後，我們再定義一個”環境角色”，假設我們這個環境角色就使用價格物件吧*/public class Price {private DiscountStrategy discountStrategy;/*** 定義一個無參構造，用於例項物件*/private Price(DiscountStrategy discountStrategy) {this.discountStrategy = discountStrategy;}/*** 獲取折扣後的價格** @param price 原始價格* @return*/public CalculationResult discount(Long userId,BigDecimal price) {return discountStrategy.getDiscountPrice(userId ,price);}}
模板設計模式
▐模式定義
模板的價值就在於骨架的定義，骨架內部將問題處理的流程已經定義好，通用的處理邏輯一般由父類實現，個性化的處理邏輯由子類實現。
比如炒土豆絲和炒麻婆豆腐，大體邏輯都是：
1、切菜
2、放油
3、炒菜
4、出鍋
1，2，4 都差不多，但是第 3 步是不一樣的，炒土豆絲得拿鏟子翻炒，但是炒麻婆豆腐得拿勺子輕推，否則豆腐會爛。
▐使用場景
不同場景的處理流程，部分邏輯是通用的，可以放到父類中作為通用實現，部分邏輯是個性化的，需要子類去個性實現。
模板模式（Template Pattern）中，一個抽象類公開定義了執行它的方法的方式/模板。它的子類可以按需要重寫方法實現，但呼叫將以抽象類中定義的方式進行。這種型別的設計模式屬於行為型模式。
▐實踐經驗
還是接著之前商品折扣的例子來說，後期我們新加了兩個需求：
使用者享受不同折扣增加 trace。
使用者享受折扣後是否升級會員等級。
所以現在的流程變成了這樣：
1、trace 開始。
2、計算使用者不同折扣力度。
3、是否允許升級會員等級，如果允許執行升級會員等級邏輯。
4、trace 結束。
其中 1 和 4 是通用的，2 和 3 是個性化的，鑑於此可以在折扣策略之前增加了一層父類的策略，將通用邏輯放到了父類中。
修改後的程式碼如下：
abstract class AbstractDiscountStrategy implements DiscountStrategy{public CalculationResult getDiscountPrice(Long userId ,BigDecimal price) {//1.構造spanSpan span = buildSpan();//2.具體通道推送邏輯由子類實現CalculationResult calculationResult =getCalculationResult(userId,price);//3.是否允許升級會員等級，如果允許執行升級邏輯if(!calculationResult.isSuccess() && canUpgrade()){upgradeLevel(userId,calculationResult);}//4.trace結束span.finish();return calculationResult;}//具體推送邏輯由子類實現protected abstract CalculationResult getCalculationResult(Long userId,BigDecimal price) ;//是否允許升級會員等級由子類實現protected abstract boolean canUpgrade(Long userId,CallResult callResult);}/*** 滿減活動 -- 滿300減80*/public class FullReductionStrategyOne extends AbstractDiscountStrategy {protectedCalculationResult getCalculationResult(Long userId,BigDecimal price){//執行折扣邏輯}protected boolean canUpgrade(Long userId,CallResult callResult){return false}}
觀察者設計模式
▐模式定義
拍賣的時候，拍賣師觀察最高標價，然後通知給其他競價者競價 這種模式就可以使用觀察者模式。顧名思義，此模式需要有觀察者（Observer）和被觀察者（Observable）兩類角色。當 Observable 狀態變化時會通知 Observer，Observer 一般會實現一類通用的介面。
比如 java.util.Observer，Observable 需要通知 Observer 時，逐個呼叫 Observer 的 update 方法即可，Observer 的處理成功與否不應該影響 Observable 的流程。
▐使用場景
當物件間存在一對多關係時，則使用觀察者模式（Observer Pattern）。比如，當一個物件被修改時，則會自動通知依賴它的物件。觀察者模式屬於行為型模式。
一個物件（Observable）狀態改變需要通知其他物件，Observer 的存在不影響 Observable 的處理結果，Observer 的增刪對 Observable 無感知。
比如 Kafka 的訊息訂閱，Producer 傳送一條訊息到 Topic，至於是 1 個還是 10 個 Consumer 訂閱這個 Topic，Producer 是不需要關注的。
▐實踐經驗
在責任鏈設計模式那塊我通過三個 Filter 解決了登出信用卡限制檢驗的問題，其中有一個 Filter 是用來檢驗使用者積分的，我這裡只是讀取使用者的積分總額和次數，那麼消費次數獲得積分的累加是怎麼完成的呢？
其實累加這塊就用到了觀察者模式，具體來講是這樣，當交易系統收到支付成功回撥時會通過 Spring 的事件機制釋出“支付成功事件”。
這樣負責積分消費次數累加和負責語音播報的訂閱者就會收到“支付成功事件”，進而做各自的業務邏輯。
畫個簡單的圖描述一下：
/**支付回撥處理者*/PayCallBackController implements ApplicationContextAware {private ApplicationContext applicationContext;//如果想獲取applicationContext需要實現ApplicationContextAware介面，Spring容器會回撥setApplicationContext方法將applicationContext注入進來public void setApplicationContext(ApplicationContext applicationContext)throws BeansException {this.applicationContext = applicationContext;}(value = "/pay/callback.do")public View callback(HttpServletRequest request){if(paySuccess(request){//構造支付成功事件PaySuccessEvent event = buildPaySuccessEvent(...);//通過applicationContext釋出事件，從而達到通知觀察者的目的this.applicationContext.publishEvent(event);}}}/*** 語音播報處理者**/public class VoiceBroadcastHandler implements ApplicationListener<PaySuccessEvent>{public void onApplicationEvent(PaySuccessEvent event) {//語音播報邏輯}}//其他處理者的邏輯類似
總結：觀察者模式將被觀察者和觀察者之間做了解耦，觀察者存在與否不會影響被觀察者的現有邏輯。
裝飾器設計模式
▐模式定義
裝飾器模式（Decorator Pattern）允許向一個現有的物件新增新的功能，同時又不改變其結構。這種型別的設計模式屬於結構型模式，它是作為現有的類的一個包裝。這種模式建立了一個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。
裝飾器用來包裝原有的類，在對使用者透明的情況下做功能的增強，比如 Java 中的 BufferedInputStream 可以對其包裝的 InputStream 做增強，從而提供緩衝功能。
▐使用場景
在不影響其他物件的情況下，以動態、透明的方式給單個物件新增職責。需要動態地給一個物件增加功能，這些功能也可以動態地被撤銷。 當不能採用繼承的方式對系統進行擴充套件或者繼承。希望對原有類的功能做增強，但又不希望增加過多子類時，可以使用裝飾器模式來達到同樣的效果。
▐實踐經驗
有一個咖啡店，銷售各種各樣的咖啡，拿鐵，卡布奇洛，藍山咖啡等，在沖泡前，會詢問顧客是否要加糖，加奶，加薄荷等。這樣不同的咖啡配上不同的調料就會賣出不同的價格。
/*** 抽象類Coffee*/public abstract class Coffee {/*** 獲取咖啡得名字*/public abstract String getName();/*** 獲取咖啡的價格*/public abstract double getPrice();}/***利用繼承和組合的結合,現在我們可以考慮設計出一個裝飾類，它也繼承自coffee，*並且它內部有一個coffee的例項物件*/public abstract class CoffeeDecorator implements Coffee {private Coffee delegate;public CoffeeDecorator(Coffee coffee) {this.delegate = coffee;}@Overridepublic String getName() {return delegate.getName();}@Overridepublic double getPrice() {return delegate.getPrice();}}/***牛奶咖啡的裝飾者模式的案例*/public class MilkCoffeeDecorator extends CoffeeDecorator {public MilkCoffeeDecorator(Coffee coffee) {super(coffee);}@Overridepublic String getName() {return "牛奶, " + super.getName();}@Overridepublic double getPrice() {return 1.1 + super.getPrice();}}//其他咖啡的模式類似/***測試案例 可以通過加入不用內容 咖啡名稱和價格都是不同的*/public class App {public static void main(String[] args) {// 得到一杯原始的藍山咖啡Coffee blueCoffee = new BlueCoffee();System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());// 加入牛奶blueCoffee = new MilkCoffeeDecorator(blueCoffee);System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());// 再加入薄荷blueCoffee = new MintCoffeeDecorator(blueCoffee);System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());// 再加入糖blueCoffee = new SugarCoffeeDecorator(blueCoffee);System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());}}
總結：使用裝飾器模式做了功能的增強，對使用者來說只需要做簡單的組合就能繼續使用原功能。裝飾器模式充分展示了組合的靈活。利用它來實現擴充套件。它同時也是開閉原則的體現。如果相對某個類實現執行時功能動態的擴充套件。這個時候你就可以考慮使用裝飾者模式！
橋接設計模式
▐模式定義
橋接模式是一種結構型設計模式，可將一個大類或一系列緊密相關的類拆分為抽象和實現兩個獨立的層次結構，從而能在開發時分別使用。
橋接（Bridge）是用於把抽象化與實現化解耦，使得二者可以獨立變化。這種型別的設計模式屬於結構型模式，它通過提供抽象化和實現化之間的橋接結構，來實現二者的解耦。
▐使用場景
如果一個系統需要在抽象類和具體類之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承關係，通過橋接模式可以使它們在抽象層建立一個關聯關係。
抽象部分和實現部分可以以繼承的方式獨立擴充套件而互不影響，在程式執行時可以動態的將一個抽象類子類的物件和一個實現類子類的物件進行組合，及系統需要對抽象類角色和實現類角色進行動態耦合。
一個類存在兩個（或多個）獨立變化的維度，且這兩個（或多個）維度都需要獨立進行擴充套件。
對於那些不希望使用繼承或因為多層繼承導致系統的個數急劇增加的系統，橋接模式尤為適用。
▐實踐經驗
效能管理系統中，資料產生後需要經過採集，匯聚，入庫三個流程，使用者才能查詢使用。採集可以是snmp採集，也可以是ems採集；匯聚可以使storm匯聚，也可以是spark匯聚；入庫可以是hdfs入庫，也可以是mppdb入庫。針對不同場景，我們可以靈活選擇不同的採集，匯聚，入庫方式。這種一個功能需要多種服務支援，每種服務又有不同型別的實現，使用橋接模式再適合不過。
橋接模式，顧名思義，就是把每種服務看做一座橋，我們可以根據實際場景選擇不同的橋。上述例子表示資料產生到可以使用之前需要經過三座橋：採集橋->匯聚橋->入庫橋。每座橋可以選擇不同的構造。
/**** 採集橋採集服務**/public abstract class CollectionService{abstract void execute();public void run(){execute();}}/*** 匯聚橋 匯聚服務**/public abstract class AggregationService{public void run(){if(null != collectionService){collectionService.run();}execute();}abstract void execute();CollectionService collectionService;public AggregationService(CollectionService collectionService){this.collectionService = collectionService;}}/**** 入庫橋 入庫服務**/public abstract class StoreService{public void run(){if(null != aggregationService){aggregationService.run();}execute();}abstract void execute();AggregationService aggregationService;public StoreService(AggregationService aggregationService){this.aggregationService = aggregationService;}}/**** EMS採集橋**/public class EMSCollectionService extends CollectionService{void execute(){System.out.println("EMS collection.");}}/**** SNMP採集橋**/public class SNMPCollectionService extends CollectionService{void execute(){System.out.println("SNMP collection.");}}/**** Storm匯聚橋**/public class StormAggregationService extends AggregationService{public StormAggregationService(CollectionService collectionService){super(collectionService);}void execute(){System.out.println("Storm aggregation.");}}/**** Spark匯聚橋**/public class SparkAggregationService extends AggregationService{public SparkAggregationService(CollectionService collectionService){super(collectionService);}void execute(){System.out.println("Spark aggregation.");}}/**** MPPDB匯聚橋**/public class MPPDBStoreService extends StoreService{public MPPDBStoreService(AggregationService aggregationService){super(aggregationService);}void execute(){System.out.println("MPPDB store.");}}/**** HDFS匯聚橋**/public class HDFSStoreService extends StoreService{public HDFSStoreService(AggregationService aggregationService){super(aggregationService);}void execute(){System.out.println("HDFS store.");}}/**** 類功能說明: 橋接模式測試*/public class BridgeTest{public static void main(String[] args){CollectionService snmpService = new SNMPCollectionService();AggregationService stormService = new StormAggregationService(snmpService);StoreService hdfsService = new HDFSStoreService(stormService);hdfsService.run();}}
總結：橋接模式可以將系統中穩定的部分和可擴充套件的部分解耦，使得系統更加容易擴充套件，且滿足OCP原則，對呼叫者修改關閉。
✿拓展閱讀
本文分享自微信公眾號 - 淘系技術（AlibabaMTT）。
如有侵權，請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。