在谈我的方法之前，不妨先用个例子来说明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”, “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);
}
或者有人会说，这样用户也需额外了解多几个方法。我个人觉得让用户了解多几个方法好过了解多几个类，而已方法名一看就能知道意图，成本还是挺小，是可以接受的。
最后
总而言之，成功是留给准备好的人的。无论是参加什么面试，都要做好充足的准备，注意好面试的礼仪和穿着，向面试官表现出自己的热忱与真诚就好。即使最后没有过关，也要做好经验的总结，为下一次面试做好充足准备。
这里我为大家准备了一些我在面试后整理的面试专题资料，除了面试题，还总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案，并整理做成了文档，以及系统的进阶学习视频资料分享给大家，希望能帮助到你面试前的复习，且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。
毕竟不管遇到什么样的面试官，去面试首先最主要的就是自己的实力，只要实力够硬，技术够强，就不怕面试拿不到offer！
为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！
法。我个人觉得让用户了解多几个方法好过了解多几个类，而已方法名一看就能知道意图，成本还是挺小，是可以接受的。
最后
总而言之，成功是留给准备好的人的。无论是参加什么面试，都要做好充足的准备，注意好面试的礼仪和穿着，向面试官表现出自己的热忱与真诚就好。即使最后没有过关，也要做好经验的总结，为下一次面试做好充足准备。
这里我为大家准备了一些我在面试后整理的面试专题资料，除了面试题，还总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案，并整理做成了文档，以及系统的进阶学习视频资料分享给大家，希望能帮助到你面试前的复习，且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。
毕竟不管遇到什么样的面试官，去面试首先最主要的就是自己的实力，只要实力够硬，技术够强，就不怕面试拿不到offer！
[外链图片转存中…(img-jWtdrbP6-1720113633812)]
[外链图片转存中…(img-K2qEClL7-1720113633812)]
为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！
[外链图片转存中…(img-8wHqKAz5-1720113633813)]
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
