后端思維篇：如何應(yīng)用設(shè)計模式優(yōu)化代碼
前言
大家好，我是撿田螺的小男孩。
本文內(nèi)容就是：在原有代碼基礎(chǔ)上，如何一步步通過設(shè)計模式去優(yōu)化代碼?日常工作中，我們用得最多的設(shè)計模式，就是策略模式、工廠模式和模板方法模式啦。最近剛好用這幾種模式優(yōu)化了代碼，所以今天跟大家聊聊，我是怎么優(yōu)化的，思路是怎么樣的。希望本文對大家有幫助哈。
- 優(yōu)化前偽代碼的流程
- 策略模式是如何應(yīng)用進去的
- 工廠設(shè)計模式是怎么使用的
- 模板方法模式又是怎么應(yīng)用進去的。
- 嘮叨幾句
1. 優(yōu)化前偽代碼流程
大家先看下，優(yōu)化前，原有代碼的大概邏輯哈。代碼如下：
class Parameter{
int pageSize;
int pageNo;
int reqNum；
//其他參數(shù)。
}
//邏輯處理，是否命中客群
boolean isMarketHit(Parameter dto){
//如果是企業(yè)客群類型
if(dto.type == 'enterprise'){
//開關(guān)關(guān)閉不請求
if(isEnterpriseSwitchClose){
return false;
}
//請求只有一條記錄的話
if(dto.reqNum==1){
//調(diào)用大數(shù)據(jù)的點查接口
return singleRemoteEOIinvoke(dto);
//請求超過一條的話
}else if(dto.reqNum>1){
//調(diào)用大數(shù)據(jù)的批量接口
return batchRemoteEOIinvoke(dto);
}
//如果是市場營銷類型
}else if(dto.type=='market_list'){
//開關(guān)關(guān)閉不請求
if(isMarketListSwitchClose){
return false;
}
//請求只有一條記錄的話
if(dto.reqNum==1){
//調(diào)用營銷的點查接口
return singleRemoteMarketinvoke(dto);
//請求超過一條的話
}else if(dto.reqNum>1){
//調(diào)用營銷的批量接口
return batchRemoteMarketinvoke(dto);
}
}
}
這個代碼可能存在哪些問題呢?
- 如果if分支變多的話，代碼就會變得臃腫。
- 如果你需要接入一種新的類型，只能在源代碼修改。
說得專業(yè)一點點，就是以上代碼，違背了面向?qū)ο蟮拈_閉原則和單一原則。
- 開閉原則：(對于擴展是開放的，對于修改是封閉的)，增加或者刪除某個邏輯，都需要修改原來的代碼。
- 單一原則：(規(guī)定一個類應(yīng)該只有一個發(fā)生變化的原因)，修改任何類型的分支邏輯代碼，都需要修改當(dāng)前類的代碼。
2. 策略模式是如何應(yīng)用進去的
大家是否還記得，如果代碼中有多個if...else等條件分支，并且每個條件分支，可以封裝起來替換的，我們就可以使用策略模式來優(yōu)化。
回憶一下，什么是策略模式呢?
策略模式定義了算法族，分別封裝起來，讓它們之間可以相互替換，此模式讓算法的變化獨立于使用算法的的客戶。這個策略模式的定義是不是有點抽象呢?打個通俗易懂的比喻：
假設(shè)你跟不同性格類型的小姐姐約會，要用不同的策略，有的請電影比較好，有的則去吃小吃效果不錯，有的去逛街買買買最合適。當(dāng)然，目的都是為了得到小姐姐的芳心，請看電影、吃小吃、逛街就是不同的策略。
策略模式針對一組算法，將每一個算法封裝到實現(xiàn)共同接口的不同獨立的類中，從而使得它們可以相互替換。策略模式我們一般是怎么定義的呢?
- 一個接口或者抽象類，里面兩個方法(一個方法匹配類型，一個可替換的邏輯實現(xiàn)方法)。
- 不同策略的差異化實現(xiàn)(就是說，不同策略的實現(xiàn)類)。
所以，對于原有的偽代碼流程，我們就可以定義企業(yè)客群類型的策略實現(xiàn)類，和市場營銷類型的策略實現(xiàn)類。這兩個策略實現(xiàn)類都實現(xiàn)了兩個方法，一個方法是匹配類型的，就是返回原始代碼if...else條件判斷的類型;然后另外個方法，就是if...else條件的實現(xiàn)內(nèi)容。代碼如下：
//一個接口
interface IGroupLabelStrategyService {
//這個方法對應(yīng)策略實現(xiàn)類的具體實現(xiàn)
boolean processBiz(Parameter dto);
//這個方法就是策略類的類型，也就是對應(yīng)```if...else```條件判斷的類型
String getType();
}
//企業(yè)客群類型的策略實現(xiàn)類
EnterpriseGroupLablelStrategyServiceImpl implements IGroupLabelStrategyService{
//對應(yīng)企業(yè)客群類型的條件分支里面的實現(xiàn)
boolean processBiz(Parameter dto){
//開關(guān)關(guān)閉不請求
if(isEnterpriseSwitchClose){
return false;
}
//請求只有一條記錄的話
if(dto.reqNum==1){
//調(diào)用大數(shù)據(jù)的點查接口
return singleRemoteEOIinvoke(dto);
//請求超過一條的話
}else if(dto.reqNum>1){
//調(diào)用遠程大數(shù)據(jù)批量接口
return batchRemoteEOIinvoke(dto);
}
}
//對應(yīng)企業(yè)類型
String getType(){
return "enterprise";
}
}
//市場營銷類型的策略實現(xiàn)類
MarketListGroupLablelStrategyServiceImpl implements IGroupLabelStrategyService{
//對應(yīng)市場營銷類型的條件分支里面的實現(xiàn)
boolean processBiz(Parameter dto){
//開關(guān)關(guān)閉不請求
if(isMarketListSwitchClose){
return false;
}
//請求只有一條記錄的話
if(dto.reqNum==1){
//調(diào)用營銷點查接口
return singleRemoteMarketinvoke(dto);
//請求超過一條的話
}else if(dto.reqNum>1){
//調(diào)用營銷批量接口
return batchRemoteMarketinvoke(dto);
}
}
String getType(){
return "market_list";
}
}
3. 工廠設(shè)計模式是怎么使用的
每個策略現(xiàn)在都實現(xiàn)好了，不同策略的實現(xiàn)類怎么交給spring管理呢?
我們可以實現(xiàn)ApplicationContextAware接口，把策略的實現(xiàn)類注入到一個map，然后根據(jù)請求方不同的策略請求類型，去實現(xiàn)不同的調(diào)用嘛，其實就是類似于工廠模式的思想啦。代碼如下：
@Component
public class GroupLabelStrategyServiceFactory implements ApplicationContextAware{
//存放對應(yīng)的類型和實現(xiàn)類
private Map<String, IGroupLabelStrategyService> map = new ConcurrentHashMap<>();
//策略實現(xiàn)類注入到map
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
Map<String, IGroupLabelStrategyService> tempMap = applicationContext.getBeansOfType(IGroupLabelStrategyService.class);
tmepMap.values().forEach(strategyService -> map.put(strategyService.getType(), strategyService));
}
//工廠方法
public boolean processBiz(ParamDTO dto){
//根據(jù)不同類型，獲取不同的實現(xiàn)類
IGroupLabelStrategyService groupLabelStrategyService= map.get(dto.getType());
if (batchGroupLabelJudgeService != null) {
return groupLabelStrategyService.processBiz(dto);
}
return false;
}
}
有了策略模式+工廠方法模式后，我們偽代碼流程簡化成這樣啦：
class Parameter{
int pageSize;
int pageNo;
int reqNum；
//其他參數(shù)。
}
boolean isMarketHit(Parameter dto){
//直接調(diào)用工廠類就可以啦，其他邏輯處理已經(jīng)在策略實現(xiàn)類里面了。
return groupLabelStrategyServiceFactory.processBiz(dto);
}
4. 模板方法模式又是怎么應(yīng)用進去的
小伙伴們，細心回頭觀察下原先的偽代碼流程，會發(fā)現(xiàn)一個共性的代碼流程，就是先開關(guān)控制，然后根據(jù)請求數(shù)量決定走單筆調(diào)用還是批量調(diào)用。
這就可以使用模板方法繼續(xù)優(yōu)化了。所謂模板方法模式，其實就是：
定義一個操作中的算法的骨架流程，而將一些步驟延遲到子類中，使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。它的核心思想就是：定義一個操作的一系列步驟，對于某些暫時確定不下來的步驟，就留給子類去實現(xiàn)，這樣不同的子類就可以定義出不同的步驟。
為了通俗易懂一點，打個比喻：
追女朋友要先“牽手”，再“擁抱”，再“接吻”， 再“拍拍..額..手”。至于具體你用左手還是右手牽，無所謂，但是整個過程，定了一個流程模板，按照模板來就行。
模板方法使用比較簡單：
- 一個抽象類，定義骨架流程(抽象方法放一起)。
- 確定的共同方法步驟，放到抽象類(去除抽象方法標記)。
- 不確定的步驟，給子類去差異化實現(xiàn)。
我們只需要把開關(guān)控制接口，單筆遠程調(diào)用、批量遠程調(diào)用這個通用共性的流程，定義到模板抽象類就好啦。代碼如下：
public abstract AbstractGroupLabelJudgeTemplate implements IGroupLabelStrategyService{
//模板骨架
public boolean processBiz（Parameter dto）{
if(isSwitchClose){
return false;
}
if(dto.reqNum==1){
return singleRemote(dto);
}else if(dto.reqNum>1){
return batchRemote(dto);
}
}
//開關(guān)由子類控制
abstract boolean isSwitchClose();
//單筆遠程調(diào)用，由子類控制
astract boolean singleRemote(dto);
//批量遠程調(diào)用，由子類控制
astract boolean batchRemote(dto);
}
不同的策略子類自己控制開關(guān)，和控制不同接口的調(diào)用即可。
EnterpriseGroupLablelStrategyServiceImpl extends AbstractGroupLabelJudgeTemplate{
boolean isSwitchClose(){
//企業(yè)客群開關(guān)
}
boolean singleRemote(ParamDTO dto){
//企業(yè)客群單筆調(diào)用
return singleRemoteEOIinvoke(dto);
}
boolean batchRemote(ParamDTO dto){
//企業(yè)客群批量調(diào)用
return batchRemoteEOIinvoke(dto);
}
}
MarketListGroupLablelStrategyServiceImpl extends AbstractGroupLabelJudgeTemplate{
boolean isSwitchClose(){
//營銷客群開關(guān)
}
boolean singleRemote(ParamDTO dto){
//營銷客群單筆調(diào)用
return singleRemoteMarketinvoke(dto);
}
boolean batchRemote(ParamDTO dto){
//營銷客群批量調(diào)用
return batchRemoteMarketinvoke(dto);
}
}
5. 嘮叨幾句
策略模式、工廠模式和模板方法模式這三種設(shè)計模式，是日常開發(fā)用得最多的。本文呢，也是闡述了我是如何在原有代碼上，抽取出設(shè)計模式的。
