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