做者：leowudev 原文：http://www.apkbus.com/blog-970703-78964.html
寫在前面
不知你們有沒遇到過像「橫放着的金字塔」同樣的if else嵌套：html
if (true) {
if (true) {
if (true) {
if (true) {
if (true) {
if (true) {
}
}
}
}
}
}
我並沒誇大其詞，我是真的遇到過了！嵌套六、7層，一個函數幾百行，簡！直！看！死！人！java
if else做爲每種編程語言都不可或缺的條件語句，咱們在編程時會大量的用到。但if else通常不建議嵌套超過三層，若是一段代碼存在過多的if else嵌套，代碼的可讀性就會急速降低，後期維護難度也大大提升。因此，咱們程序員都應該儘可能避免過多的if else嵌套。下面將會談談我在工做中如何減小if else嵌套的。程序員
正文
在談個人方法以前，不妨先用個例子來講明if else嵌套過多的弊端。編程
想象下一個簡單分享的業務需求：支持分享連接、圖片、文本和圖文，分享結果回調給用戶（爲了避免跑題，這裏簡略了業務，實際複雜得多）。當接手到這麼一個業務時，是否是以爲很簡單，稍動下腦就能夠動手了：緩存
先定義分享的類型、分享Bean和分享回調類：微信
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);
}
好了，而後在定義個分享接口，對每種類型分別進行分享就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");
}
}
}
到此，簡單的分享模型就作出來了。有沒問題？老實說，若是沒什麼追求的話，還真沒什麼問題，至少思路是清晰的。但一週後呢？一個月後呢？或者一年後呢？share方法的分支有15條，這意味着你每次回看代碼得讓本身的大腦變成微型的處理器，考慮15種狀況。若是出現bug，你又得考慮15種狀況，並15種狀況都要測試下。再若是如今須要加多分享小視頻功能，你又得添加多3個分支，還要改代碼，一點都不「開放-閉合」。再再若是後面項目交接給他人跟進，他人又要把本身大腦變成處理器來想每一個分支的做用，我敢確定有百分之八十的人都會吐槽代碼。ide
咱們程序員的腦力不該該花費在無止境的分支語句裏的，應該專一於業務自己。因此咱們頗有必要避免寫出多分支嵌套的語句。好的，咱們來分析下上面的代碼多分支的緣由：函數
空值判斷測試
業務判斷
狀態判斷
幾乎全部的業務都離不開這幾個判斷，從而致使if else嵌套過多。那是否是沒辦法解決了？答案確定不是的。
上面的代碼我是用java寫的，對於java程序員來講，空值判斷簡直令人很沮喪，讓人身心疲憊。上面的代碼每次回調都要判斷一次listener是否爲空，又要判斷用戶傳入的ShareItem是否爲空，還要判斷ShareItem裏面的字段是否爲空……
對於這種狀況，我採用的方法很簡單：接口分層。
減小 if else 方法一：接口分層
所謂接口分層指的是：把接口分爲外部和內部接口，全部空值判斷放在外部接口完成，只處理一次；而內部接口傳入的變量由外部接口保證不爲空，從而減小空值判斷。
來，看代碼更加直觀：
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() {
@Override
public 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和內部接口shareImpl，ShareItem和ShareListener的判斷都放在share裏完成，那麼shareImpl就減小了if else的嵌套了，至關於把if else分攤了。這樣一來，代碼的可讀性好不少，嵌套也不超過3層了。
但能夠看到，shareImpl裏仍是包含分享類型的判斷，也即業務判斷，咱們都清楚產品經理的腦洞有多大了，分享的類型隨時會改變或添加。嗯說到這裏相信你們都想到用多態了。多態不但能應付業務改變的狀況，也能夠用來減小if else的嵌套。
減小 if else 方法二：多態
利用多態，每種業務單獨處理，在接口再也不作任何業務判斷。把ShareItem抽象出來，做爲基礎類，而後針對每種業務各自實現其子類：
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";
}
@Override
public 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";
}
@Override
public 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";
}
@Override
public 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";
}
@Override
public void doShare(ShareListener listener) {
// do share
}
}
（注意：上面每一個子類的構造方法還對每一個字段作了空值處理，爲空的話，賦值default，這樣若是用戶傳了空值，在調試就會發現問題。）
實現了多態後，分享接口的就簡潔多了：
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() {
@Override
public 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);
}
嘻嘻，怎樣，內部接口一個if else都沒了，是否是很酷~ 若是這個分享功能是本身App裏面的功能，不是第三方SDK，到這裏已經沒問題了。但若是是第三方分享SDK的功能的話，這樣暴露給用戶的類增長了不少（各ShareItem的子類，至關於把if else拋給用戶了），用戶的接入成本提升，違背了「迪米特原則」了。
處理這種狀況也很簡單，再次封裝一層便可。把ShareItem的子類的訪問權限下降，在暴露給用戶的主類裏定義幾個方法，在內部幫助用戶建立具體的分享類型，這樣用戶就無需知道具體的類了：
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);
}
或者有人會說，這樣用戶也需額外瞭解多幾個方法。我我的以爲讓用戶瞭解多幾個方法好過了解多幾個類，而已方法名一看就能知道意圖，成本仍是挺小，是能夠接受的。
其實這種狀況，更多人想到的是使用工廠模式。嗯，工廠模式能解決這個問題（其實也須要用戶額外瞭解多幾個type類型），但工廠模式不免又引入分支，咱們能夠用Map消除分支。
減小 if else 方法三：使用Map替代分支語句
把全部分享類型預先緩存在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(); // 返回默認實現，不要返回null
}
}
這種方式跟上面分爲幾個方法的方式各有利弊，看你們取捨了~
寫在最後
講到這裏你們有沒收穫呢？總結下減小if else的方法：
把接口分爲外部和內部接口，全部空值判斷放在外部接口完成；而內部接口傳入的變量由外部接口保證不爲空，從而減小空值判斷。
利用多態，把業務判斷消除，各子類分別關注本身的實現，並實現子類的建立方法，避免用戶瞭解過多的類。
把分支狀態信息預先緩存在
Map裏，直接get獲取具體值，消除分支。
好了，到此就介紹完了，但願你們之後寫代碼能注意，有則避之，無則加勉。但願你們寫的代碼愈來愈簡潔。
本文分享自微信公衆號 - 編程微刊（wangxiaoting678）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。