不知大家有沒遇到過像“橫放著的金字塔”一樣的if else嵌套:
<code>if (true) {
if (true) {
if (true) {
if (true) {
if (true) {
if (true) {
}
}
}
}
}
}
/<code>
我並沒誇大其詞,我是真的遇到過了!嵌套6、7層,一個函數幾百行,簡!直!看!死!人!
if else作為每種編程語言都不可或缺的條件語句,我們在編程時會大量的用到。但if else一般不建議嵌套超過三層,如果一段代碼存在過多的if else嵌套,代碼的可讀性就會急速下降,後期維護難度也大大提高。
所以,我們程序員都應該儘量避免過多的if else嵌套。下面將會談談我在工作中如何減少if else嵌套的。
在談我的方法之前,不妨先用個例子來說明if else嵌套過多的弊端。
想象下一個簡單分享的業務需求:支持分享鏈接、圖片、文本和圖文,分享結果回調給用戶(為了不跑題,這裡簡略了業務,實際複雜得多)。當接手到這麼一個業務時,是不是覺得很簡單,稍動下腦就可以動手了。
先定義分享的類型、分享Bean和分享回調類:
<code>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);
}
/<code>
好了,然後在定義個分享接口,對每種類型分別進行分享就ok了:
<code>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");
}
}
}
/<code>
到此,簡單的分享模型就做出來了。
有沒有問題?老實說,如果沒什麼追求的話,還真沒什麼問題,至少思路是清晰的。但一週後呢?一個月後呢?或者一年後呢?
share方法的分支有15條,這意味著你每次回看代碼得讓自己的大腦變成微型的處理器,考慮15種情況。如果出現bug,你又得考慮15種情況,並15種情況都要測試下。再如果現在需要加多分享小視頻功能,你又得添加多3個分支,還要改代碼,一點都不“開放-閉合”。再再如果後面項目交接給他人跟進,他人又要把自己大腦變成處理器來想每個分支的作用,我敢肯定有百分之八十的人都會吐槽代碼。
我們程序員的腦力不應該花費在無止境的分支語句裡的,應該專注於業務本身。所以我們很有必要避免寫出多分支嵌套的語句。好的,我們來分析下上面的代碼多分支的原因:
- 空值判斷
- 業務判斷
- 狀態判斷
幾乎所有的業務都離不開這幾個判斷,從而導致if else嵌套過多。那是不是沒辦法解決了?答案肯定不是的。
上面的代碼我是用java寫的,對於java程序員來說,空值判斷簡直使人很沮喪,讓人身心疲憊。上面的代碼每次回調都要判斷一次listener是否為空,又要判斷用戶傳入的ShareItem是否為空,還要判斷ShareItem裡面的字段是否為空......
對於這種情況,我採用的方法很簡單:接口分層。
減少 if else 方法一:接口分層
所謂接口分層指的是:把接口分為外部和內部接口,所有空值判斷放在外部接口完成,只處理一次;而內部接口傳入的變量由外部接口保證不為空,從而減少空值判斷。
來,看代碼更加直觀:
<code>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, "不支持的分享類型");
}
}
/<code>
可以看到,上面的代碼分為外部接口share和內部接口shareImpl,ShareItem和ShareListener的判斷都放在share裡完成,那麼shareImpl就減少了if else的嵌套了,相當於把if else分攤了。這樣一來,代碼的可讀性好很多,嵌套也不超過3層了。
但可以看到,shareImpl裡還是包含分享類型的判斷,也即業務判斷,我們都清楚產品經理的腦洞有多大了,分享的類型隨時會改變或添加。嗯說到這裡相信大家都想到用多態了。多態不但能應付業務改變的情況,也可以用來減少if else的嵌套。
減少 if else 方法二:多態
利用多態,每種業務單獨處理,在接口不再做任何業務判斷。
把ShareItem抽象出來,作為基礎類,然後針對每種業務各自實現其子類:
<code>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
}
}
/<code>
(注意:上面每個子類的構造方法還對每個字段做了空值處理,為空的話,賦值default,這樣如果用戶傳了空值,在調試就會發現問題。)
實現了多態後,分享接口的就簡潔多了:
<code>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);
}
/<code>
嘻嘻,怎樣,內部接口一個if else都沒了,是不是很酷~
如果這個分享功能是自己App裡面的功能,不是第三方SDK,到這裡已經沒問題了。但如果是第三方分享SDK的功能的話,這樣暴露給用戶的類增加了很多(各ShareItem的子類,相當於把if else拋給用戶了),用戶的接入成本提高,違背了“迪米特原則”了。
處理這種情況也很簡單,再次封裝一層即可。把ShareItem的子類的訪問權限降低,在暴露給用戶的主類裡定義幾個方法,在內部幫助用戶創建具體的分享類型,這樣用戶就無需知道具體的類了:
<code>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);
}
/<code>
或者有人會說,這樣用戶也需額外瞭解多幾個方法。我個人覺得讓用戶瞭解多幾個方法好過了解多幾個類,而已方法名一看就能知道意圖,成本還是挺小,是可以接受的。
其實這種情況,更多人想到的是使用工廠模式。嗯,工廠模式能解決這個問題(其實也需要用戶額外瞭解多幾個type類型),但工廠模式難免又引入分支,我們可以用Map消除分支。
減少 if else 方法三:使用Map替代分支語句
把所有分享類型預先緩存在Map裡,那麼就可以直接get獲取具體類型,消除分支:
<code>private Map<integer>> 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
}
}
/<integer>/<code>
這種方式跟上面分為幾個方法的方式各有利弊,看大家取捨了~
- 講到這裡大家有沒收穫呢?總結下減少if else的方法:
- 把接口分為外部和內部接口,所有空值判斷放在外部接口完成;而內部接口傳入的變量由外部接口保證不為空,從而減少空值判斷。
- 利用多態,把業務判斷消除,各子類分別關注自己的實現,並實現子類的創建方法,避免用戶瞭解過多的類。
- 把分支狀態信息預先緩存在Map裡,直接get獲取具體值,消除分支。
好了,到此就介紹完了,希望大家以後寫代碼能注意,有則避之,無則加勉。希望大家寫的代碼越來越簡潔~
鏈接:https://my.oschina.net/u/4477286/blog/3198041
閱讀更多 Java架構師阿谷 的文章