安卓大叔

来源：www.jianshu.com/p/57c065b124c4

写在前面

不知大家有没遇到过像“横放着的金字塔”一样的if else嵌套：

if (true) { if (true) { if (true) { if (true) { if (true) { if (true) {  } } } } }}

我并没夸大其词，我是真的遇到过了！嵌套6、7层，一个函数几百行，简！直！看！死！人！

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个分支，还要改代码，一点都不“开放-闭合”。再再如果后面项目交接给他人跟进，他人又要把自己大脑变成处理器来想每个分支的作用，我敢肯定有百分之八十的人都会吐槽代码。

我们程序员的脑力不应该花费在无止境的分支语句里的，应该专注于业务本身。所以我们很有必要避免写出多分支嵌套的语句。好的，我们来分析下上面的代码多分支的原因：

1. 空值判断
2. 业务判断
3. 状态判断

几乎所有的业务都离不开这几个判断，从而导致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