前言：
最近因为工作中业务需要，代码里用了大量的if else嵌套。想着如何优化，刚好在网上看到一篇文章，个人觉得写的还不错。这边转载过来以后后续学习。根据个人理解和需要，自己做了一点修改整理。
作者：leowudev 原文：http://www.apkbus.com/blog-970703-78964.html(已征得原文作者同意，后续转载需注明来源！！！)
写在前面：
不知大家有没遇到过像“横放着的金字塔”一样的if else嵌套：
1 if (true) {2 if (true) {3 if (true) {4 if (true) {5 if (true) {6 if (true) {7
8 }9 }10 }11 }12 }13 }
我并没夸大其词，我是真的遇到过了！嵌套6、7层，一个函数几百行，简！直！看！死！人！
if else作为每种编程语言都不可或缺的条件语句，我们在编程时会大量的用到。但if else一般不建议嵌套超过三层，如果一段代码存在过多的if else嵌套，代码的可读性就会急速下降，后期维护难度也大大提高。所以，我们程序员都应该尽量避免过多的if else嵌套。下面将会谈谈我在工作中如何减少if else嵌套的。
正文：
在谈我的方法之前，不妨先用个例子来说明if else嵌套过多的弊端。
想象下一个简单分享的业务需求：支持分享链接、图片、文本和图文，分享结果回调给用户(为了不跑题，这里简略了业务，实际复杂得多)。当接手到这么一个业务时，是不是觉得很简单，稍动下脑就可以动手了：
先定义分享的类型、分享Bean和分享回调类：
1 private static final int TYPE_LINK = 0;2 private static final int TYPE_IMAGE = 1;3 private static final int TYPE_TEXT = 2;4 private static final int TYPE_IMAGE_TEXT = 3;5
6 public classShareItem {7 inttype;8 String title;9 String content;10 String imagePath;11 String link;12 }13
14 public interfaceShareListener {15
16 int STATE_SUCC = 0;17 int STATE_FAIL = 1;18
19 void onCallback(intstate, String msg);20 }
好了，然后在定义个分享接口，对每种类型分别进行分享就ok了：
1 public voidshare (ShareItem item, ShareListener listener) {2 if (item != null) {3 if (item.type ==TYPE_LINK) {4 //分享链接
5 if (!TextUtils.isEmpty(item.link) && !TextUtils.isEmpty(item.title)) {6 doShareLink(item.link, item.title, item.content, listener);7 } else{8 if (listener != null) {9 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");10 }11 }12 } else if (item.type ==TYPE_IMAGE) {13 //分享图片
14 if (!TextUtils.isEmpty(item.imagePath)) {15 doShareImage(item.imagePath, listener);16 } else{17 if (listener != null) {18 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");19 }20 }21 } else if (item.type ==TYPE_TEXT) {22 //分享文本
23 if (!TextUtils.isEmpty(item.content)) {24 doShareText(item.content, listener);25 } else{26 if (listener != null) {27 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");28 }29 }30 } else if (item.type ==TYPE_IMAGE_TEXT) {31 //分享图文
32 if (!TextUtils.isEmpty(item.imagePath) && !TextUtils.isEmpty(item.content)) {33 doShareImageAndText(item.imagePath, item.content, listener);34 } else{35 if (listener != null) {36 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");37 }38 }39 } else{40 if (listener != null) {41 listener.onCallback(ShareListener.STATE_FAIL, "不支持的分享类型");42 }43 }44 } else{45 if (listener != null) {46 listener.onCallback(ShareListener.STATE_FAIL, "ShareItem 不能为 null");47 }48 }49 }
到此，简单的分享模型就做出来了。有没问题？老实说，如果没什么追求的话，还真没什么问题，至少思路是清晰的。但一周后呢？一个月后呢？或者一年后呢？share方法的分支有15条，这意味着你每次回看代码得让自己的大脑变成微型的处理器，考虑15种情况。如果出现bug，你又得考虑15种情况，并15种情况都要测试下。再如果现在需要加多分享小视频功能，你又得添加多3个分支，还要改代码，一点都不“开放-闭合”。再再如果后面项目交接给他人跟进，他人又要把自己大脑变成处理器来想每个分支的作用，我敢肯定有百分之八十的人都会吐槽代码。
我们程序员的脑力不应该花费在无止境的分支语句里的，应该专注于业务本身。所以我们很有必要避免写出多分支嵌套的语句。好的，我们来分析下上面的代码多分支的原因：
空值判断
业务判断
状态判断
几乎所有的业务都离不开这几个判断，从而导致if else嵌套过多。那是不是没办法解决了？答案肯定不是的。
上面的代码我是用java写的，对于java程序员来说，空值判断简直使人很沮丧，让人身心疲惫。上面的代码每次回调都要判断一次listener是否为空，又要判断用户传入的ShareItem是否为空，还要判断ShareItem里面的字段是否为空……
对于这种情况，我采用的方法很简单：接口分层。
减少 if else 方法一：接口分层
所谓接口分层指的是：把接口分为外部和内部接口，所有空值判断放在外部接口完成，只处理一次；而内部接口传入的变量由外部接口保证不为空，从而减少空值判断。
来，看代码更加直观：
1 public voidshare(ShareItem item, ShareListener listener) {2 if (item == null) {3 if (listener != null) {4 listener.onCallback(ShareListener.STATE_FAIL, "ShareItem 不能为 null");5 }6 return;7 }8
9 if (listener == null) {10 listener = newShareListener() {11 @Override12 public void onCallback(intstate, String msg) {13 Log.i("DEBUG", "ShareListener is null");14 }15 };16 }17
18 shareImpl(item, listener);19 }20
21 private voidshareImpl (ShareItem item, ShareListener listener) {22 if (item.type ==TYPE_LINK) {23 //分享链接
24 if (!TextUtils.isEmpty(item.link) && !TextUtils.isEmpty(item.title)) {25 doShareLink(item.link, item.title, item.content, listener);26 } else{27 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");28 }29 } else if (item.type ==TYPE_IMAGE) {30 //分享图片
31 if (!TextUtils.isEmpty(item.imagePath)) {32 doShareImage(item.imagePath, listener);33 } else{34 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");35 }36 } else if (item.type ==TYPE_TEXT) {37 //分享文本
38 if (!TextUtils.isEmpty(item.content)) {39 doShareText(item.content, listener);40 } else{41 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");42 }43 } else if (item.type ==TYPE_IMAGE_TEXT) {44 //分享图文
45 if (!TextUtils.isEmpty(item.imagePath) && !TextUtils.isEmpty(item.content)) {46 doShareImageAndText(item.imagePath, item.content, listener);47 } else{48 listener.onCallback(ShareListener.STATE_FAIL, "分享信息不完整");49 }50 } else{51 listener.onCallback(ShareListener.STATE_FAIL, "不支持的分享类型");52 }53 }
可以看到，上面的代码分为外部接口share和内部接口shareImpl，ShareItem和ShareListener的判断都放在share里完成，那么shareImpl就减少了if else的嵌套了，相当于把if else分摊了。这样一来，代码的可读性好很多，嵌套也不超过3层了。
但可以看到，shareImpl里还是包含分享类型的判断，也即业务判断，我们都清楚产品经理的脑洞有多大了，分享的类型随时会改变或添加。嗯说到这里相信大家都想到用多态了。多态不但能应付业务改变的情况，也可以用来减少if else的嵌套。
减少 if else 方法二：多态
利用多态，每种业务单独处理，在接口不再做任何业务判断。把ShareItem抽象出来，作为基础类，然后针对每种业务各自实现其子类：
1 public abstract classShareItem {2 inttype;3
4 public ShareItem(inttype) {5 this.type =type;6 }7
8 public abstract voiddoShare(ShareListener listener);9 }10
11 public class Link extendsShareItem {12 String title;13 String content;14 String link;15
16 publicLink(String link, String title, String content) {17 super(TYPE_LINK);18 this.link = !TextUtils.isEmpty(link) ? link : "default";19 this.title = !TextUtils.isEmpty(title) ? title : "default";20 this.content = !TextUtils.isEmpty(content) ? content : "default";21 }22
23 @Override24 public voiddoShare(ShareListener listener) {25 //do share
26 }27 }28
29 public class Image extendsShareItem {30 String imagePath;31
32 publicImage(String imagePath) {33 super(TYPE_IMAGE);34 this.imagePath = !TextUtils.isEmpty(imagePath) ? imagePath : "default";35 }36
37 @Override38 public voiddoShare(ShareListener listener) {39 //do share
40 }41 }42
43 public class Text extendsShareItem {44 String content;45
46 publicText(String content) {47 super(TYPE_TEXT);48 this.content = !TextUtils.isEmpty(content) ? content : "default";49 }50
51 @Override52 public voiddoShare(ShareListener listener) {53 //do share
54 }55 }56
57 public class ImageText extendsShareItem {58 String content;59 String imagePath;60
61 publicImageText(String imagePath, String content) {62 super(TYPE_IMAGE_TEXT);63 this.imagePath = !TextUtils.isEmpty(imagePath) ? imagePath : "default";64 this.content = !TextUtils.isEmpty(content) ? content : "default";65 }66
67 @Override68 public voiddoShare(ShareListener listener) {69 //do share
70 }71 }
(注意：上面每个子类的构造方法还对每个字段做了空值处理，为空的话，赋值default，这样如果用户传了空值，在调试就会发现问题。)
实现了多态后，分享接口的就简洁多了：
public voidshare(ShareItem item, ShareListener listener) {if (item == null) {if (listener != null) {
listener.onCallback(ShareListener.STATE_FAIL,"ShareItem 不能为 null");
}return;
}if (listener == null) {
listener= newShareListener() {
@Overridepublic void onCallback(intstate, String msg) {
Log.i("DEBUG", "ShareListener is null");
}
};
}
shareImpl(item, listener);
}private voidshareImpl (ShareItem item, ShareListener listener) {
item.doShare(listener);
}
嘻嘻，怎样，内部接口一个if else都没了，是不是很酷~ 如果这个分享功能是自己App里面的功能，不是第三方SDK，到这里已经没问题了。但如果是第三方分享SDK的功能的话，这样暴露给用户的类增加了很多(各ShareItem的子类，相当于把if else抛给用户了)，用户的接入成本提高，违背了“迪米特原则”了。
处理这种情况也很简单，再次封装一层即可。把ShareItem的子类的访问权限降低，在暴露给用户的主类里定义几个方法，在内部帮助用户创建具体的分享类型，这样用户就无需知道具体的类了：
1 publicShareItem createLinkShareItem(String link, String title, String content) {2 return newLink(link, title, content);3 }4
5 publicShareItem createImageShareItem(String ImagePath) {6 return newImage(ImagePath);7 }8
9 publicShareItem createTextShareItem(String content) {10 return newText(content);11 }12
13 publicShareItem createImageTextShareItem(String ImagePath, String content) {14 return newImageText(ImagePath, content);15 }
或者有人会说，这样用户也需额外了解多几个方法。我个人觉得让用户了解多几个方法好过了解多几个类，而已方法名一看就能知道意图，成本还是挺小，是可以接受的。
其实这种情况，更多人想到的是使用工厂模式。嗯，工厂模式能解决这个问题(其实也需要用户额外了解多几个type类型)，但工厂模式难免又引入分支，我们可以用Map消除分支。
以上，由于转载的代码结构不是很清晰，为了后续学习的时候能更清楚理解，我自己把这部分代码整理了一下。
目录结构：
分享的类型：
回调类：
定义一个ShareItem的抽象类：
具体的实现类：
减少 if else 方法三：使用Map替代分支语句
把所有分享类型预先缓存在Map里，那么就可以直接get获取具体类型，消除分支：
1 private Map> map = new HashMap<>();2
3 private voidinit() {4 map.put(TYPE_LINK, Link.class);5 map.put(TYPE_IMAGE, Image.class);6 map.put(TYPE_TEXT, Text.class);7 map.put(TYPE_IMAGE_TEXT, ImageText.class);8 }9
10 public ShareItem createShareItem(inttype) {11 try{12 Class extends ShareItem> shareItemClass =map.get(type);13 returnshareItemClass.newInstance();14 } catch(Exception e) {15 return new DefaultShareItem(); //返回默认实现，不要返回null
16 }17 }
这种方式跟上面分为几个方法的方式各有利弊，看大家取舍了~