看完這篇，code?review?誰敢噴你代碼寫的爛？懟回去！

時(shí)間：2021-08-18 08:40:48

關(guān)鍵字： view 代碼 ev

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]??我將常用的軟件設(shè)計(jì)模式，做了匯總，目錄如下：(考慮到內(nèi)容篇幅較大，為了便于大家閱讀，將軟件設(shè)計(jì)模式系列（共23個(gè)）拆分成四篇文章，每篇文章講解六個(gè)設(shè)計(jì)模式，采用不同的顏色區(qū)分，便于快速消化記憶）本文，主要講解模板模式、策略模式、狀態(tài)模式、觀察者模式、訪問者模式、備忘錄模式1、...

??我將常用的軟件設(shè)計(jì)模式，做了匯總，目錄如下：

(考慮到內(nèi)容篇幅較大，為了便于大家閱讀，將軟件設(shè)計(jì)模式系列（共23個(gè)）拆分成四篇文章，每篇文章講解六個(gè)設(shè)計(jì)模式，采用不同的顏色區(qū)分，便于快速消化記憶）

本文，主要講解模板模式、策略模式、狀態(tài)模式、觀察者模式、訪問者模式、備忘錄模式

1、模板模式

定義：

定義一個(gè)操作中的算法的骨架，將一些步驟延遲到子類中。模板模式使得子類可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。

優(yōu)點(diǎn)：1、封裝不變部分，擴(kuò)展可變部分。2、提取公共代碼，便于維護(hù)。3、行為由父類控制，子類實(shí)現(xiàn)。缺點(diǎn)：每一個(gè)不同的實(shí)現(xiàn)都需要一個(gè)子類來實(shí)現(xiàn)，導(dǎo)致類的個(gè)數(shù)增加，維護(hù)成本高。

核心思路：

AbstractTemplate：定義一個(gè)完整的框架，方法的調(diào)用順序已經(jīng)確定，但會定義一些抽象的方法留給子類去實(shí)現(xiàn)
AHandler：具體的業(yè)務(wù)子類，實(shí)現(xiàn)AbstractTemplate中定義的抽象方法，從而形成一個(gè)完整的流程邏輯

代碼示例：

public?TradeFlowActionResult?execute(TradeFlowActionParam?param,?Map?context)?throws?ServiceException?{
????try?{????//?業(yè)務(wù)邏輯校驗(yàn)
????????this.validateBusinessLogic(param,?context);
????}?catch?(ServiceException?ex)?{
????????sendGoodsLog.info("SendGoodsAction->validateBusinessLogic?got?exception.?param?is?"? ?param,?ex);
????????throw?ex;
????}?catch?(RuntimeException?ex)?{
????????sendGoodsLog.info("SendGoodsAction->validateBusinessLogic?got?runtime?exception.?param?is?"? ?param,?ex);
????????throw?ex;
????}
????try?{
????????//?賣家發(fā)貨業(yè)務(wù)邏輯
????????this.sendGoods(param,?context);
????}?catch?(ServiceException?ex)?{
????????sendGoodsLog.info("SendGoodsAction->sendGoods?got?exception.?param?is?"? ?param,?ex);
????????throw?ex;
????}?catch?(RuntimeException?ex)?{
????????sendGoodsLog.info("SendGoodsAction->sendGoods?got?runtime?exception.?param?is?"? ?param,?ex);
????????throw?ex;
????}
????try?{
????????//?補(bǔ)充業(yè)務(wù)（結(jié)果不影響核心業(yè)務(wù)）
????????this.addition(param,?context);
????}?catch?(ServiceException?ex)?{
????????sendGoodsLog.info("SendGoodsAction->addition?got?exception.?param?is?"? ?param,?ex);
????????throw?ex;
????}?catch?(RuntimeException?ex)?{
????????sendGoodsLog.info("SendGoodsAction->addition?got?runtime?exception.?param?is?"? ?param,?ex);
????????throw?ex;
????}
????//?處理結(jié)果
????return?null;
}

上面提到的三個(gè)抽象方法（業(yè)務(wù)邏輯校驗(yàn)、賣家發(fā)貨業(yè)務(wù)邏輯、補(bǔ)充業(yè)務(wù)）都是在子類中實(shí)現(xiàn)的。即控制了主流程結(jié)構(gòu)，又不失靈活性，可以讓使用者在其基礎(chǔ)上定制開發(fā)。如果有新的業(yè)務(wù)玩法進(jìn)來，原來的流程滿足不了需求，我們可以基于模板類編寫新的子類。

適用場景：

希望控制算法的主流程，不能隨意變更框架，但又想保留子類業(yè)務(wù)的個(gè)性擴(kuò)展。
去除重復(fù)代碼。保留父類通用的代碼邏輯，讓子類不再需要重復(fù)處理公用邏輯，只關(guān)注特定邏輯，起到去除子類中重復(fù)代碼的目的。
案例很多，比如 Jenkins 的拉取代碼、編譯、打包、發(fā)布、部署的流程作為一個(gè)通用的流程，不同系統(tǒng)（java、python、nodejs等）可以根據(jù)自身的需求開發(fā)，定制自己的持續(xù)發(fā)布流程。

2、策略模式

定義：

定義一系列算法，并將每種算法分別放入獨(dú)立的類中，以使算法的對象能夠相互替換。

由客戶端自己決定在什么樣的情況下使用哪些具體的策略。

核心思路：

上下文信息類（Context）：使用不同的策略環(huán)境，根據(jù)自身的條件選擇不同的策略實(shí)現(xiàn)類來完成所需要的操作。他持有一個(gè)策略實(shí)例的引用。
抽象策略類（Strategy）：抽象策略，定義每個(gè)策略都要實(shí)現(xiàn)的方法
具體策略類（A Realize）：負(fù)責(zé)實(shí)現(xiàn)抽象策略中定義的策略方法。

代碼示例：

/**
?*?@author 微信公眾號：微觀技術(shù)
?*/
public?interface?PromotionStrategy?{
????//?活動類型
????String?promotionType();
????//?活動優(yōu)惠
????int?recommand(String?productId);
}

public?class?FullSendPromotion?implements?PromotionStrategy?{
????@Override
????public?String?promotionType()?{
????????return?"FullSend";
????}

????@Override
????public?int?recommand(String?productId)?{
????????System.out.println("參加滿送活動");
????????return?0;
????}
}

public?class?FullReducePromotion?implements?PromotionStrategy?{
????@Override
????public?String?promotionType()?{
????????return?"FullReduce";
????}

????@Override
????public?int?recommand(String?productId)?{
????????System.out.println("參加滿減活動");
????????return?0;
????}
}

@author 微信公眾號：微觀技術(shù)
public?class?Context?{

????private?static?List?promotionStrategyList?=?new?ArrayList<>();
????static?{
????????promotionStrategyList.add(new?FullReducePromotion());
????????promotionStrategyList.add(new?FullSendPromotion());
????}
????public?void?recommand(String?promotionType,?String?productId)?{
????????PromotionStrategy?promotionStrategy?=?null;
????????//?找到對應(yīng)的策略類
????????for?(PromotionStrategy?temp?:?promotionStrategyList)?{
????????????if?(temp.promotionType().equals(promotionType))?{
????????????????promotionStrategy?=?temp;
????????????}
????????}
????????//?策略子類調(diào)用
????????promotionStrategy.recommand(productId);
????}

首先，定義活動策略的接口類PromotionStrategy，定義接口方法，每一種具體的策略算法都要實(shí)現(xiàn)該接口，FullSendPromotion和FullReducePromotion。

Context負(fù)責(zé)存儲和使用策略，匯集了所有的策略子類。并根據(jù)傳入的參數(shù)，匹配到具體的策略子類，然后調(diào)用recommand方法，處理具體的業(yè)務(wù)。

使用策略的好處：

提升代碼的可維護(hù)性。不同策略類隔離，互不影響。每一次新增策略時(shí)都通過新增類來進(jìn)行隔離，避免了if-else超大的復(fù)雜類
動態(tài)快速地替換更多的算法。由于調(diào)度策略與算法實(shí)現(xiàn)分離，且接口規(guī)范固定，我們可以靈活的調(diào)整選擇不同的策略子類。

適用場景：

壓縮文件，提供了 gzip、zip 、rar 等格式，由客戶端自己選擇哪一種壓縮策略。不同策略可以相互替換。
營銷活動，根據(jù)策略路由選擇不同的活動玩法，不同的營銷活動隔離，滿足開閉原則。
選擇權(quán)交給了客戶端，適合那些經(jīng)常調(diào)整策略的to C 業(yè)務(wù)，靈活性高。

3、狀態(tài)模式

定義：

一種行為設(shè)計(jì)模式，讓你能在一個(gè)對象的內(nèi)部狀態(tài)變化時(shí)改變其行為，使其看上去就像改變了自身所屬的類一樣。

通過定義一系列狀態(tài)的變化來控制行為的變化。以電商為例，用戶的訂單會經(jīng)歷以下這些狀態(tài)：已下單、已付款、已發(fā)貨、派送中、待取件、已簽收、交易成功、交易關(guān)閉等狀態(tài)。

核心思路：

上下文信息類(OrderContext)：存儲當(dāng)前狀態(tài)的類，對外提供更新狀態(tài)的方法。
抽象狀態(tài)類（OrderState）：可以是一個(gè)接口或抽象類，用于聲明狀態(tài)更新時(shí)執(zhí)行哪些操作
具體狀態(tài)類（MakeOrderState、PayOrderState、ReceiveGoodOrderState）：實(shí)現(xiàn)抽象狀態(tài)類定義的方法，根據(jù)具體的場景來指定對應(yīng)狀態(tài)改變后的代碼實(shí)現(xiàn)邏輯。

代碼示例：

/**
?*?@author 微信公眾號：微觀技術(shù)
?*?訂單狀態(tài)，接口定義（擴(kuò)展實(shí)現(xiàn)若干不同狀態(tài)的子類）
?*/
public?interface?OrderState?{
????void?handle(OrderContext?context);
}

//?下單
public?class?MakeOrderState?implements?OrderState?{
????public?static?MakeOrderState?instance?=?new?MakeOrderState();
????@Override
????public?void?handle(OrderContext?context)?{

????????System.out.println("1、創(chuàng)建訂單");
????????context.setCurrentOrderState(PayOrderState.instance);
????}
}

//?付款、確認(rèn)收貨，實(shí)現(xiàn)類相似，這里省略。。。。

//?訂單上下文
public?class?OrderContext?{
????private?OrderState?currentOrderState;

????public?OrderContext(OrderState?currentOrderState)?{
????????if?(currentOrderState?==?null)?{
????????????this.currentOrderState?=?new?MakeOrderState();
????????}?else?{
????????????this.currentOrderState?=?currentOrderState;
????????}
????}

????public?void?setCurrentOrderState(OrderState?currentOrderState)?{
????????this.currentOrderState?=?currentOrderState;
????}

????public?void?execute()?{
????????currentOrderState.handle(this);
????}
}

運(yùn)行結(jié)果：

1、創(chuàng)建訂單
2、支付寶付款
3、確認(rèn)收到貨物

狀態(tài)模式設(shè)計(jì)的核心點(diǎn)在于找到合適的抽象狀態(tài)以及狀態(tài)之間的轉(zhuǎn)移關(guān)系，通過改變狀態(tài)來達(dá)到改變行為的目的。

適用場景：

業(yè)務(wù)需要根據(jù)狀態(tài)的變化，進(jìn)行不同的操作。比如：電商下單的全流程
不希望有大量的if-else代碼堆在一起，希望不同的狀態(tài)處理邏輯隔離，遵守開閉原則

4、觀察者模式

定義：

也稱發(fā)布-訂閱模式，是一種通知機(jī)制，當(dāng)一個(gè)對象改變狀態(tài)時(shí)，它的所有依賴項(xiàng)都會自動得到通知和更新。讓發(fā)送通知的一方（被觀察者）和接收通知的一方（觀察者，支持多個(gè)）能彼此分離，互不影響，該模式在軟件開發(fā)中非常流行。

像我們常見的Kafka、RocketMQ等消息中間件都是采用這種架構(gòu)模式，還有Spring的 ApplicationEvent 異步事件驅(qū)動，有很好的低耦合特性。

類似其他叫法：

發(fā)布者 --- 訂閱者
生產(chǎn)者 --- 消費(fèi)者
事件發(fā)布 --- 事件監(jiān)聽

核心思路：

發(fā)布者（Publisher）：定義一系列接口，用來管理和觸發(fā)訂閱者
具體發(fā)布者（PublisherImpl）：具體實(shí)現(xiàn)類，實(shí)現(xiàn)Publisher接口定義的方法
訂閱者（Observer）：觀察者接口，當(dāng)發(fā)布者發(fā)布消息或事件時(shí)，會通知到訂閱者進(jìn)行處理。
具體訂閱者（WeixinObserver、EmailObserver）：Observer的子類，用來處理具體的業(yè)務(wù)邏輯

代碼示例：

/**
?*?@author 微信公眾號：微觀技術(shù)
?*?
?*?被觀察者
?*/
public?interface?Publisher?{
????void?add(Observer?observer);
????void?remove(Observer?observer);
????void?notify(Object?object);
}

public?class?PublisherImpl?implements?Publisher?{
????private?List?observerList?=?new?ArrayList<>();
????@Override
????public?void?add(Observer?observer)?{
????????observerList.add(observer);
????}
????@Override
????public?void?remove(Observer?observer)?{
????????observerList.remove(observer);
????}
????@Override
????public?void?notify(Object?object)?{
????????System.out.println("創(chuàng)建訂單，并發(fā)送通知事件");
????????observerList.stream().forEach(t?->?t.handle());
????}
}

//?觀察者接口
public?interface?Observer?{
????public?void?handle();
}

//?觀察者子類
public?class?EmailObserver?implements?Observer?{
????@Override
????public?void?handle()?{
????????System.out.println("發(fā)送郵件通知！");
????}
}

觀察者模式的核心精髓：被觀察者定義了一個(gè)通知列表，收集了所有的觀察者對象，當(dāng)被觀察者需要發(fā)出通知時(shí)，就會通知這個(gè)列表的所有觀察者。

適用場景：

當(dāng)一個(gè)對象狀態(tài)的改變需要改變其他對象時(shí)。比如：訂單支付成功后，需要通知扣減賬戶余額
一個(gè)對象發(fā)生改變時(shí)只想要發(fā)送通知，而不需要知道接收者是誰。比如：微博feed流，粉絲能拉到最新微博
代碼的擴(kuò)展性強(qiáng)，如果需要新增一個(gè)觀察者業(yè)務(wù)處理，只需新增一個(gè)子類觀察者，并注入到被觀察者的通知列表即可，代碼的耦合性非常低。

5、訪問者模式

定義：

訪問者模式是一種將操作與對象結(jié)構(gòu)分離的軟件設(shè)計(jì)模式，允許在運(yùn)行時(shí)將一個(gè)或多個(gè)操作應(yīng)用于一組對象。

核心思路：

行為接口（RouterVisitor）：定義對每個(gè) Element 訪問的行為，方法參數(shù)就是被訪問的元素，它的方法個(gè)數(shù)理論上與元素的個(gè)數(shù)是一樣的。
行為接口實(shí)現(xiàn)類（LinuxRouterVisitor、WindowRouterVisitor）：它需要給出對每一個(gè)元素類訪問時(shí)所產(chǎn)生的具體行為。
元素接口（RouterElement）：定義一個(gè)可以獲取訪問操作的接口，使客戶端對象能夠“訪問”的入口點(diǎn)。
元素接口實(shí)現(xiàn)類（JhjRouterElement、LyqRouterElement）：將訪問者RouterVisitor傳遞給此對象作為參數(shù)。

代碼示例：

/**
?*?@author 微信公眾號：微觀技術(shù)
?*?定義行為動作
?*/
public?interface?RouterVisitor?{
????//?交換機(jī)，發(fā)送數(shù)據(jù)
????void?sendData(JhjRouterElement?jhjRouterElement);
????//?路由器，發(fā)送數(shù)據(jù)
????void?sendData(LyqRouterElement?lyqRouterElement);
}

public?class?LinuxRouterVisitor?implements?RouterVisitor?{
????@Override
????public?void?sendData(JhjRouterElement?jhjRouterElement)?{
????????System.out.println("Linux?環(huán)境下，交換機(jī)發(fā)送數(shù)據(jù)");
????}

????@Override
????public?void?sendData(LyqRouterElement?lyqRouterElement)?{
????????System.out.println("Linux?環(huán)境下，路由器發(fā)送數(shù)據(jù)");
????}
}

public?class?WindowRouterVisitor?implements?RouterVisitor?{
???//?省略。。。
}


/**
?*?@author 微信公眾號：微觀技術(shù)
?*?
?*?路由元素
?*/
public?interface?RouterElement?{
????//?發(fā)送數(shù)據(jù)
????void?sendData(RouterVisitor?routerVisitor);
}
public?class?JhjRouterElement?implements?RouterElement?{

????@Override
????public?void?sendData(RouterVisitor?routerVisitor)?{
????????System.out.println("交換機(jī)開始工作。。。");
????????routerVisitor.sendData(this);
????}
}
public?class?LyqRouterElement?implements?RouterElement?{
?//?省略。。。
}

適用場景：

動態(tài)綁定不同的對象和對象操作
通過行為與對象結(jié)構(gòu)的分離，實(shí)現(xiàn)對象的職責(zé)分離，提高代碼復(fù)用性

6、備忘錄模式

定義：

也叫快照模式，用來存儲另外一個(gè)對象內(nèi)部狀態(tài)的快照，便于以后可以恢復(fù)。

核心思路：

原始對象（Originator）：除了創(chuàng)建自身所需要的屬性和業(yè)務(wù)邏輯外，還通過提供方法 bak() 和 restore(memento) 來保存和恢復(fù)對象副本。
備忘錄（Memento）：用于保存原始對象的所有屬性狀態(tài)，以便在未來進(jìn)行恢復(fù)操作。

代碼示例：

/**
?*?@author 微信公眾號：微觀技術(shù)
?*?原始對象
?*/
@Data
public?class?Originator?{
????private?Long?id;
????private?String?productName;
????private?String?picture;
????//?創(chuàng)建快照
????public?Memento?bak()?{
????????return?new?Memento(id,?productName,?picture);
????}
????//恢復(fù)
????public?void?restore(Memento?m)?{
????????this.id?=?m.getId();
????????this.productName?=?m.getProductName();
????????this.picture?=?m.getPicture();
????}
}


//?快照
@Data
@AllArgsConstructor
public?class?Memento?{
????private?Long?id;
????private?String?productName;
????private?String?picture;
}

適用場景：

在線編輯器，不小心關(guān)閉瀏覽器，重新打開頁面，可以從草稿箱恢復(fù)之前內(nèi)容
不希望外界直接訪問對象的內(nèi)部狀態(tài)，比如：物流包裹
另外像操作系統(tǒng)自動備份，數(shù)據(jù)庫的SAVEPOINT

寫在最后

設(shè)計(jì)模式很多人都學(xué)習(xí)過，但項(xiàng)目實(shí)戰(zhàn)時(shí)總是暈暈乎乎，原因在于沒有了解其核心是什么，底層邏輯是什么，《設(shè)計(jì)模式：可復(fù)用面向?qū)ο蟮幕A(chǔ)》有講過，

在設(shè)計(jì)中思考什么應(yīng)該變化，并封裝會發(fā)生變化的概念。

軟件架構(gòu)的精髓：找到變化，封裝變化。

業(yè)務(wù)千變?nèi)f化，沒有固定的編碼答案，千萬不要硬套設(shè)計(jì)模式。無論選擇哪一種設(shè)計(jì)模式，盡量要能滿足SOLID原則，自我review是否滿足業(yè)務(wù)的持續(xù)擴(kuò)展性。有句話說的好，“不論白貓黑貓，能抓老鼠就是好貓。”