优化过多的if else嵌套

最新推荐文章于 2024-03-09 12:12:16 发布

dengjian3851

最新推荐文章于 2024-03-09 12:12:16 发布

阅读量1.8k

点赞数

文章标签： c# c/c++ r语言

原文链接：http://www.cnblogs.com/zhongjunbo555/p/11394572.html

版权

前言：

　　最近因为工作中业务需要，代码里用了大量的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 class ShareItem {
 7     int type;
 8     String title;
 9     String content;
10     String imagePath;
11     String link;
12 }
13 
14 public interface ShareListener {
15 
16     int STATE_SUCC = 0;
17     int STATE_FAIL = 1;
18 
19     void onCallback(int state, String msg);
20 }

好了，然后在定义个分享接口，对每种类型分别进行分享就ok了：

 1 public void share (ShareItem item, ShareListener listener) {
 2     if (item != null) {
 3         if (item.type == TYPE_LINK) {
 4             // 分享链接
 5             if (!TextUtils.isEmpty(item.link) &amp;&amp; !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) &amp;&amp; !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 void share(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 = new ShareListener() {
11             @Override
12             public void onCallback(int state, String msg) {
13                 Log.i("DEBUG", "ShareListener is null");
14             }
15         };
16     }
17 
18     shareImpl(item, listener);
19 }
20 
21 private void shareImpl (ShareItem item, ShareListener listener) {
22     if (item.type == TYPE_LINK) {
23         // 分享链接
24         if (!TextUtils.isEmpty(item.link) &amp;&amp; !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) &amp;&amp; !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 class ShareItem {
 2     int type;
 3 
 4     public ShareItem(int type) {
 5         this.type = type;
 6     }
 7 
 8     public abstract void doShare(ShareListener listener);
 9 }
10 
11 public class Link extends ShareItem {
12     String title;
13     String content;
14     String link;
15 
16     public Link(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     @Override
24     public void doShare(ShareListener listener) {
25         // do share
26     }
27 }
28 
29 public class Image extends ShareItem {
30     String imagePath;
31 
32     public Image(String imagePath) {
33         super(TYPE_IMAGE);
34         this.imagePath = !TextUtils.isEmpty(imagePath) ? imagePath : "default";
35     }
36 
37     @Override
38     public void doShare(ShareListener listener) {
39         // do share
40     }
41 }
42 
43 public class Text extends ShareItem {
44     String content;
45 
46     public Text(String content) {
47         super(TYPE_TEXT);
48         this.content = !TextUtils.isEmpty(content) ? content : "default";
49     }
50 
51     @Override
52     public void doShare(ShareListener listener) {
53         // do share
54     }
55 }
56 
57 public class ImageText extends ShareItem {
58     String content;
59     String imagePath;
60 
61     public ImageText(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     @Override
68     public void doShare(ShareListener listener) {
69         // do share
70     }
71 }

（注意：上面每个子类的构造方法还对每个字段做了空值处理，为空的话，赋值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的子类的访问权限降低，在暴露给用户的主类里定义几个方法，在内部帮助用户创建具体的分享类型，这样用户就无需知道具体的类了：

 1 public ShareItem createLinkShareItem(String link, String title, String content) {
 2     return new Link(link, title, content);
 3 }
 4 
 5 public ShareItem createImageShareItem(String ImagePath) {
 6     return new Image(ImagePath);
 7 }
 8 
 9 public ShareItem createTextShareItem(String content) {
10     return new Text(content);
11 }
12 
13 public ShareItem createImageTextShareItem(String ImagePath, String content) {
14     return new ImageText(ImagePath, content);
15 }

或者有人会说，这样用户也需额外了解多几个方法。我个人觉得让用户了解多几个方法好过了解多几个类，而已方法名一看就能知道意图，成本还是挺小，是可以接受的。

其实这种情况，更多人想到的是使用工厂模式。嗯，工厂模式能解决这个问题（其实也需要用户额外了解多几个type类型），但工厂模式难免又引入分支，我们可以用Map消除分支。

以上，由于转载的代码结构不是很清晰，为了后续学习的时候能更清楚理解，我自己把这部分代码整理了一下。

目录结构：

分享的类型：

回调类：

定义一个ShareItem的抽象类：

具体的实现类：

减少 if else 方法三：使用Map替代分支语句

把所有分享类型预先缓存在Map里，那么就可以直接get获取具体类型，消除分支：

 1 private Map<Integer, Class<? extends ShareItem>> map = new HashMap<>();
 2 
 3 private void init() {
 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(int type) {
11     try {
12         Class<? extends ShareItem> shareItemClass = map.get(type);
13         return shareItemClass.newInstance();
14     } catch (Exception e) {
15         return new DefaultShareItem(); // 返回默认实现，不要返回null
16     } 
17 }

这种方式跟上面分为几个方法的方式各有利弊，看大家取舍了~

转载于:https://www.cnblogs.com/zhongjunbo555/p/11394572.html

dengjian3851

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
优化过多的if else嵌套

前言：　　最近因为工作中业务需要，代码里用了大量的if else嵌套。想着如何优化，刚好在网上看到一篇文章，个人觉得写的还不错。这边转载过来以后后续学习。根据个人理解和需要，自己做了一点修改整理。作者：leowudev 原文：http://www.apkbus.com/blog-970703-78964.html（已征得原文作者同意，后续转载需注明来源！！！）写在前面：不...
复制链接

扫一扫