在業務部門的開發中，大多數的我們在完成的業務的各種需求和提供解決方案，很多場景下的我們通過 CRUD 就能解決問題，但是這樣的作業對技術人的提升并不多，如何讓自己從業務中解脫出來找到寫代碼的樂趣呢，我做過一些嘗試，使用設計模式改善自己的業務代碼就是其中的一種，讓代碼變得更加簡潔和提升健壯性，從代碼中尋找一些歡樂，
前言
阿里優秀的人很多，他們身上都有著共同的特質，就是看問題的思考能力，讓我最佩服的是思考力強的人，對事情有深入見解和觀點的人，大多數人還是停留在表面看問題，很多禁錮在思想里逃不出來，古人說，立德立言立功為三不朽，立言就是思考力和認知力，人和人的差異，在長久的職場中或者生活中，除去運氣外，其實就是認知和思考力的差異，所以除去繁瑣的作業后，如何在有限的時間從代碼中尋找歡樂，需要提高的是思考和規劃能力，整理了一份562頁設計模式PDF檔案
責任鏈設計模式
? 模式定義
責任鏈模式(Chain of Responsibility Pattern), 是行為型設計模式之一，這種模型結構有點類似現實生活中鐵鏈，由一個個鐵環首尾相接構成一條鏈，如果這種結構用在編程領域，則每個節點可以看做一個物件，每個物件有不同的處理邏輯，將一個請求從鏈的首端發出，沿著鏈的路徑依次傳遞每個節點物件，直到有物件處理這個請求為止，我們將這樣一種模式稱為責任鏈模式，
? 適用場景
適用于多節點的流程處理，每個節點完成各自負責的部分，節點之間不知道彼此的存在，比如 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 上即可，
責任鏈中一個處理者物件，其中只有兩個行為，一是處理請求，二是將請求轉送給下一個節點，不允許某個處理者物件在處理了請求后又將請求轉送給上一個節點的情況，對于一條責任鏈來說，一個請求最終只有兩種情況，一是被某個處理物件所處理，另一個是所有物件均未對其處理，前一種情況稱該責任鏈為純的責任鏈，對于后一種情況稱為不純的責任鏈，實際應用中，多為不純的責任鏈，整理了一份562頁設計模式PDF檔案
策略設計模式
? 模式定義
策略這個詞應該怎么理解，打個比方說，我們出門的時候會選擇不同的出行方式，比如騎自行車、坐公交、坐火車、坐飛機等等，這些出行方式，每一種都是一個策略，
再比如我們去逛商場，商場現在正在搞活動，有打折的、有滿減的、有返利的等等，其實不管商場如何進行促銷，說到底都是一些演算法，這些演算法本身只是一種策略，并且這些演算法是隨時都可能互相替換的，比如針對同一件商品，今天打八折、明天滿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
*/
@Override
public 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
*/
@Override
public 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);
}
}
策略模式是一種行為型模式，將演算法的使用和演算法本身分割開，委派給不同的物件管理，策略實作類一般是封裝好的輕量級的演算法，當客戶端（呼叫方）遇到不同的情況時，這些演算法可以根據需要動態地去互相替換，策略的選擇完全是由客戶端進行的，這就要求客戶端必須理解所有的策略實作類，雖然提高了系統的靈活性，但也增加了客戶端的使用難度，策略模式體現了開閉原則——“對擴展開放，對修改關閉”，新的策略增加時，不會影響其他類的修改，增加了擴展性，對擴展開放；只依賴于抽象，而不依賴于具體實作，所以對修改是關閉的，這樣在提高代碼擴展性的同時，也降低了耦合，
總結：將每種通道的推送邏輯封裝到了具體的策略中，某種策略的變更不會影響其他策略，由于實作了共同介面，所以策略可以互相替換，對使用者友好，比如 Java ThreadPoolExecutor 中的任務拒絕策略，當執行緒池已經飽和的時候會執行拒絕策略，具體的拒絕邏輯被封裝到了 RejectedExecutionHandler 的 rejectedExecution 中，
模板設計模式
? 模式定義
模板的價值就在于骨架的定義，骨架內部將問題處理的流程已經定義好，通用的處理邏輯一般由父類實作，個性化的處理邏輯由子類實作，
比如炒土豆絲和炒麻婆豆腐，大體邏輯都是：
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{
@Override
public CalculationResult getDiscountPrice(Long userId ,BigDecimal price) {
//1.構造span
Span 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 {
@Override
protectedCalculationResult getCalculationResult(Long userId,BigDecimal price){
//執行折扣邏輯
}
@Override
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注入進來
@Override
public void setApplicationContext(ApplicationContext applicationContext)
throws BeansException {
this.applicationContext = applicationContext;
}
@RequestMapping(value = "https://www.cnblogs.com/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>{
@Override
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;
}
@Override
public String getName() {
return delegate.getName();
}
@Override
public double getPrice() {
return delegate.getPrice();
}
}
/**
*牛奶咖啡的裝飾者模式的案例
*/
public class MilkCoffeeDecorator extends CoffeeDecorator {
public MilkCoffeeDecorator(Coffee coffee) {
super(coffee);
}
@Override
public String getName() {
return "牛奶, " + super.getName();
}
@Override
public 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入庫，針對不同場景，我們可以靈活選擇不同的采集，匯聚，入庫方式，這種一個功能需要多種服務支持，每種服務又有不同型別的實作，使用橋接模式再適合不過，
橋接模式，顧名思義，就是把每種服務看做一座橋，我們可以根據實際場景選擇不同的橋，上述例子表示資料產生到可以使用之前需要經過三座橋：采集橋->匯聚橋->入庫橋，每座橋可以選擇不同的構造，整理了一份562頁設計模式PDF檔案
/**
*
* 采集橋采集服務
*
*/
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
{
@Override
void execute()
{
System.out.println("EMS collection.");
}
}
/**
*
* SNMP采集橋
*
*/
public class SNMPCollectionService extends CollectionService
{
@Override
void execute()
{
System.out.println("SNMP collection.");
}
}
/**
*
* Storm匯聚橋
*
*/
public class StormAggregationService extends AggregationService
{
public StormAggregationService(CollectionService collectionService)
{
super(collectionService);
}
@Override
void execute()
{
System.out.println("Storm aggregation.");
}
}
/**
*
* Spark匯聚橋
*
*/
public class SparkAggregationService extends AggregationService
{
public SparkAggregationService(CollectionService collectionService)
{
super(collectionService);
}
@Override
void execute()
{
System.out.println("Spark aggregation.");
}
}
/**
*
* MPPDB匯聚橋
*
*/
public class MPPDBStoreService extends StoreService
{
public MPPDBStoreService(AggregationService aggregationService)
{
super(aggregationService);
}
@Override
void execute()
{
System.out.println("MPPDB store.");
}
}
/**
*
* HDFS匯聚橋
*
*/
public class HDFSStoreService extends StoreService
{
public HDFSStoreService(AggregationService aggregationService)
{
super(aggregationService);
}
@Override
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原則，對呼叫者修改關閉，
**作者：阿里巴巴淘系技術官方
***my.oschina.net/u/4662964/b…
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/245978.html
標籤：其他