减少该死的 if else 嵌套
寫在前面
不知大家有沒遇到過像“橫放著的金字塔”一樣的if else嵌套：
if?(true)?{if?(true)?{if?(true)?{if?(true)?{if?(true)?{if?(true)?{}}}}} }我并沒夸大其詞，我是真的遇到過了！嵌套6、7層，一個(gè)函數(shù)幾百行，簡！直！看！死！人！
if else作為每種編程語言都不可或缺的條件語句，我們在編程時(shí)會(huì)大量的用到。但if else一般不建議嵌套超過三層，如果一段代碼存在過多的if else嵌套，代碼的可讀性就會(huì)急速下降，后期維護(hù)難度也大大提高。所以，我們程序員都應(yīng)該盡量避免過多的if else嵌套。下面將會(huì)談?wù)勎以诠ぷ髦腥绾螠p少if else嵌套的。
聽說有圖會(huì)更多人看正文
在談我的方法之前，不妨先用個(gè)例子來說明if else嵌套過多的弊端。
想象下一個(gè)簡單分享的業(yè)務(wù)需求：支持分享鏈接、圖片、文本和圖文，分享結(jié)果回調(diào)給用戶（為了不跑題，這里簡略了業(yè)務(wù)，實(shí)際復(fù)雜得多）。當(dāng)接手到這么一個(gè)業(yè)務(wù)時(shí)，是不是覺得很簡單，稍動(dòng)下腦就可以動(dòng)手了：
先定義分享的類型、分享Bean和分享回調(diào)類：
private?static?final?int?TYPE_LINK?=?0; private?static?final?int?TYPE_IMAGE?=?1; private?static?final?int?TYPE_TEXT?=?2; private?static?final?int?TYPE_IMAGE_TEXT?=?3;public?class?ShareItem?{int?type;String?title;String?content;String?imagePath;String?link; }public?interface?ShareListener?{int?STATE_SUCC?=?0;int?STATE_FAIL?=?1;void?onCallback(int?state,?String?msg); }好了，然后在定義個(gè)分享接口，對(duì)每種類型分別進(jìn)行分享就ok了：
public?void?share?(ShareItem?item,?ShareListener?listener)?{if?(item?!=?null)?{if?(item.type?==?TYPE_LINK)?{//?分享鏈接if?(!TextUtils.isEmpty(item.link)?&&?!TextUtils.isEmpty(item.title))?{doShareLink(item.link,?item.title,?item.content,?listener);}?else?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}}?else?if?(item.type?==?TYPE_IMAGE)?{//?分享圖片if?(!TextUtils.isEmpty(item.imagePath))?{doShareImage(item.imagePath,?listener);}?else?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}}?else?if?(item.type?==?TYPE_TEXT)?{//?分享文本if?(!TextUtils.isEmpty(item.content))?{doShareText(item.content,?listener);}?else?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}}?else?if?(item.type?==?TYPE_IMAGE_TEXT)?{//?分享圖文if?(!TextUtils.isEmpty(item.imagePath)?&&?!TextUtils.isEmpty(item.content))?{doShareImageAndText(item.imagePath,?item.content,?listener);}?else?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}}?else?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"不支持的分享類型");}}}?else?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"ShareItem?不能為?null");}} }到此，簡單的分享模型就做出來了。有沒問題？老實(shí)說，如果沒什么追求的話，還真沒什么問題，至少思路是清晰的。但一周后呢？一個(gè)月后呢？或者一年后呢？share方法的分支有15條，這意味著你每次回看代碼得讓自己的大腦變成微型的處理器，考慮15種情況。如果出現(xiàn)bug，你又得考慮15種情況，并15種情況都要測試下。再如果現(xiàn)在需要加多分享小視頻功能，你又得添加多3個(gè)分支，還要改代碼，一點(diǎn)都不“開放-閉合”。再再如果后面項(xiàng)目交接給他人跟進(jìn)，他人又要把自己大腦變成處理器來想每個(gè)分支的作用，我敢肯定有百分之八十的人都會(huì)吐槽代碼。
我們程序員的腦力不應(yīng)該花費(fèi)在無止境的分支語句里的，應(yīng)該專注于業(yè)務(wù)本身。所以我們很有必要避免寫出多分支嵌套的語句。好的，我們來分析下上面的代碼多分支的原因：
空值判斷
業(yè)務(wù)判斷
狀態(tài)判斷
幾乎所有的業(yè)務(wù)都離不開這幾個(gè)判斷，從而導(dǎo)致if else嵌套過多。那是不是沒辦法解決了？答案肯定不是的。
上面的代碼我是用java寫的，對(duì)于java程序員來說，空值判斷簡直使人很沮喪，讓人身心疲憊。上面的代碼每次回調(diào)都要判斷一次listener是否為空，又要判斷用戶傳入的ShareItem是否為空，還要判斷ShareItem里面的字段是否為空……
對(duì)于這種情況，我采用的方法很簡單：接口分層。
減少 if else 方法一：接口分層
所謂接口分層指的是：把接口分為外部和內(nèi)部接口，所有空值判斷放在外部接口完成，只處理一次；而內(nèi)部接口傳入的變量由外部接口保證不為空，從而減少空值判斷。
來，看代碼更加直觀：
public?void?share(ShareItem?item,?ShareListener?listener)?{if?(item?==?null)?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"ShareItem?不能為?null");}return;}if?(listener?==?null)?{listener?=?new?ShareListener()?{@Overridepublic?void?onCallback(int?state,?String?msg)?{Log.i("DEBUG",?"ShareListener?is?null");}};}shareImpl(item,?listener); }private?void?shareImpl?(ShareItem?item,?ShareListener?listener)?{if?(item.type?==?TYPE_LINK)?{//?分享鏈接if?(!TextUtils.isEmpty(item.link)?&&?!TextUtils.isEmpty(item.title))?{doShareLink(item.link,?item.title,?item.content,?listener);}?else?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}?else?if?(item.type?==?TYPE_IMAGE)?{//?分享圖片if?(!TextUtils.isEmpty(item.imagePath))?{doShareImage(item.imagePath,?listener);}?else?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}?else?if?(item.type?==?TYPE_TEXT)?{//?分享文本if?(!TextUtils.isEmpty(item.content))?{doShareText(item.content,?listener);}?else?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}?else?if?(item.type?==?TYPE_IMAGE_TEXT)?{//?分享圖文if?(!TextUtils.isEmpty(item.imagePath)?&&?!TextUtils.isEmpty(item.content))?{doShareImageAndText(item.imagePath,?item.content,?listener);}?else?{listener.onCallback(ShareListener.STATE_FAIL,?"分享信息不完整");}}?else?{listener.onCallback(ShareListener.STATE_FAIL,?"不支持的分享類型");} }可以看到，上面的代碼分為外部接口share和內(nèi)部接口shareImpl，ShareItem和ShareListener的判斷都放在share里完成，那么shareImpl就減少了if else的嵌套了，相當(dāng)于把if else分?jǐn)偭恕＿@樣一來，代碼的可讀性好很多，嵌套也不超過3層了。
但可以看到，shareImpl里還是包含分享類型的判斷，也即業(yè)務(wù)判斷，我們都清楚產(chǎn)品經(jīng)理的腦洞有多大了，分享的類型隨時(shí)會(huì)改變或添加。嗯說到這里相信大家都想到用多態(tài)了。多態(tài)不但能應(yīng)付業(yè)務(wù)改變的情況，也可以用來減少if else的嵌套。
減少 if else 方法二：多態(tài)
利用多態(tài)，每種業(yè)務(wù)單獨(dú)處理，在接口不再做任何業(yè)務(wù)判斷。把ShareItem抽象出來，作為基礎(chǔ)類，然后針對(duì)每種業(yè)務(wù)各自實(shí)現(xiàn)其子類：
public?abstract?class?ShareItem?{int?type;public?ShareItem(int?type)?{this.type?=?type;}public?abstract?void?doShare(ShareListener?listener); }public?class?Link?extends?ShareItem?{String?title;String?content;String?link;public?Link(String?link,?String?title,?String?content)?{super(TYPE_LINK);this.link?=?!TextUtils.isEmpty(link)???link?:?"default";this.title?=?!TextUtils.isEmpty(title)???title?:?"default";this.content?=?!TextUtils.isEmpty(content)???content?:?"default";}@Overridepublic?void?doShare(ShareListener?listener)?{//?do?share} }public?class?Image?extends?ShareItem?{String?imagePath;public?Image(String?imagePath)?{super(TYPE_IMAGE);this.imagePath?=?!TextUtils.isEmpty(imagePath)???imagePath?:?"default";}@Overridepublic?void?doShare(ShareListener?listener)?{//?do?share} }public?class?Text?extends?ShareItem?{String?content;public?Text(String?content)?{super(TYPE_TEXT);this.content?=?!TextUtils.isEmpty(content)???content?:?"default";}@Overridepublic?void?doShare(ShareListener?listener)?{//?do?share} }public?class?ImageText?extends?ShareItem?{String?content;String?imagePath;public?ImageText(String?imagePath,?String?content)?{super(TYPE_IMAGE_TEXT);this.imagePath?=?!TextUtils.isEmpty(imagePath)???imagePath?:?"default";this.content?=?!TextUtils.isEmpty(content)???content?:?"default";}@Overridepublic?void?doShare(ShareListener?listener)?{//?do?share} }（注意：上面每個(gè)子類的構(gòu)造方法還對(duì)每個(gè)字段做了空值處理，為空的話，賦值default，這樣如果用戶傳了空值，在調(diào)試就會(huì)發(fā)現(xiàn)問題。）
實(shí)現(xiàn)了多態(tài)后，分享接口的就簡潔多了：
public?void?share(ShareItem?item,?ShareListener?listener)?{if?(item?==?null)?{if?(listener?!=?null)?{listener.onCallback(ShareListener.STATE_FAIL,?"ShareItem?不能為?null");}return;}if?(listener?==?null)?{listener?=?new?ShareListener()?{@Overridepublic?void?onCallback(int?state,?String?msg)?{Log.i("DEBUG",?"ShareListener?is?null");}};}shareImpl(item,?listener); }private?void?shareImpl?(ShareItem?item,?ShareListener?listener)?{item.doShare(listener); }嘻嘻，怎樣，內(nèi)部接口一個(gè)if else都沒了，是不是很酷~ 如果這個(gè)分享功能是自己App里面的功能，不是第三方SDK，到這里已經(jīng)沒問題了。但如果是第三方分享SDK的功能的話，這樣暴露給用戶的類增加了很多（各ShareItem的子類，相當(dāng)于把if else拋給用戶了），用戶的接入成本提高，違背了“迪米特原則”了。
處理這種情況也很簡單，再次封裝一層即可。把ShareItem的子類的訪問權(quán)限降低，在暴露給用戶的主類里定義幾個(gè)方法，在內(nèi)部幫助用戶創(chuàng)建具體的分享類型，這樣用戶就無需知道具體的類了：
public?ShareItem?createLinkShareItem(String?link,?String?title,?String?content)?{return?new?Link(link,?title,?content); }public?ShareItem?createImageShareItem(String?ImagePath)?{return?new?Image(ImagePath); }public?ShareItem?createTextShareItem(String?content)?{return?new?Text(content); }public?ShareItem?createImageTextShareItem(String?ImagePath,?String?content)?{return?new?ImageText(ImagePath,?content); }或者有人會(huì)說，這樣用戶也需額外了解多幾個(gè)方法。我個(gè)人覺得讓用戶了解多幾個(gè)方法好過了解多幾個(gè)類，而已方法名一看就能知道意圖，成本還是挺小，是可以接受的。
其實(shí)這種情況，更多人想到的是使用工廠模式。嗯，工廠模式能解決這個(gè)問題（其實(shí)也需要用戶額外了解多幾個(gè)type類型），但工廠模式難免又引入分支，我們可以用Map消除分支。
減少 if else 方法三：使用Map替代分支語句
把所有分享類型預(yù)先緩存在Map里，那么就可以直接get獲取具體類型，消除分支：
private?Map<Integer,?Class<??extends?ShareItem>>?map?=?new?HashMap<>();private?void?init()?{map.put(TYPE_LINK,?Link.class);map.put(TYPE_IMAGE,?Image.class);map.put(TYPE_TEXT,?Text.class);map.put(TYPE_IMAGE_TEXT,?ImageText.class); }public?ShareItem?createShareItem(int?type)?{try?{Class<??extends?ShareItem>?shareItemClass?=?map.get(type);return?shareItemClass.newInstance();}?catch?(Exception?e)?{return?new?DefaultShareItem();?//?返回默認(rèn)實(shí)現(xiàn)，不要返回null}? }這種方式跟上面分為幾個(gè)方法的方式各有利弊，看大家取舍了~
寫在最后
講到這里大家有沒收獲呢？總結(jié)下減少if else的方法：
-
把接口分為外部和內(nèi)部接口，所有空值判斷放在外部接口完成；而內(nèi)部接口傳入的變量由外部接口保證不為空，從而減少空值判斷。
-
利用多態(tài)，把業(yè)務(wù)判斷消除，各子類分別關(guān)注自己的實(shí)現(xiàn)，并實(shí)現(xiàn)子類的創(chuàng)建方法，避免用戶了解過多的類。
-
把分支狀態(tài)信息預(yù)先緩存在Map里，直接get獲取具體值，消除分支。
好了，到此就介紹完了，希望大家以后寫代碼能注意，有則避之，無則加勉。希望大家寫的代碼越來越簡潔~
總結(jié)
以上是生活随笔為你收集整理的减少该死的 if else 嵌套的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 小米自动化运维平台演进设计思路
- 下一篇： 渔村小厂，如何成长为5G霸王？