減少該死的 if else 嵌套 Day34 2018-12-24

今日偶然看到一篇研究減少if else嵌套的文章，里面利用接口分層、利用多態(tài)、使用Map替代分支語句的方式，給我啟迪頗多，謹(jǐn)此記錄。
來源：減少該死的 if else 嵌套

寫在前面

不知大家有沒遇到過像“橫放著的金字塔”一樣的if else嵌套：

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

                    }
                }
            }
        }
    }
}

我并沒夸大其詞，我是真的遇到過了！嵌套6、7層，一個(gè)函數(shù)幾百行，簡！直！看！死！人！

if else作為每種編程語言都不可或缺的條件語句，我們在編程時(shí)會大量的用到。但if else一般不建議嵌套超過三層，如果一段代碼存在過多的if else嵌套，代碼的可讀性就會急速下降，后期維護(hù)難度也大大提高。所以，我們程序員都應(yīng)該盡量避免過多的if else嵌套。下面將會談?wù)勎以诠ぷ髦腥绾螠p少if else嵌套的。

聽說有圖會更多人看

正文

在談我的方法之前，不妨先用個(gè)例子來說明if else嵌套過多的弊端。

想象下一個(gè)簡單分享的業(yè)務(wù)需求：支持分享鏈接、圖片、文本和圖文，分享結(jié)果回調(diào)給用戶（為了不跑題，這里簡略了業(yè)務(wù)，實(shí)際復(fù)雜得多）。當(dāng)接手到這么一個(gè)業(yè)務(wù)時(shí)，是不是覺得很簡單，稍動下腦就可以動手了：

先定義分享的類型、分享Bean和分享回調(diào)類：

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);
}

好了，然后在定義個(gè)分享接口，對每種類型分別進(jìn)行分享就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");
        }
    }
}

到此，簡單的分享模型就做出來了。有沒問題？老實(shí)說，如果沒什么追求的話，還真沒什么問題，至少思路是清晰的。但一周后呢？一個(gè)月后呢？或者一年后呢？share方法的分支有15條，這意味著你每次回看代碼得讓自己的大腦變成微型的處理器，考慮15種情況。如果出現(xiàn)bug，你又得考慮15種情況，并15種情況都要測試下。再如果現(xiàn)在需要加多分享小視頻功能，你又得添加多3個(gè)分支，還要改代碼，一點(diǎn)都不“開放-閉合”。再再如果后面項(xiàng)目交接給他人跟進(jìn)，他人又要把自己大腦變成處理器來想每個(gè)分支的作用，我敢肯定有百分之八十的人都會吐槽代碼。

我們程序員的腦力不應(yīng)該花費(fèi)在無止境的分支語句里的，應(yīng)該專注于業(yè)務(wù)本身。所以我們很有必要避免寫出多分支嵌套的語句。好的，我們來分析下上面的代碼多分支的原因：

  • 空值判斷

  • 業(yè)務(wù)判斷

  • 狀態(tài)判斷

幾乎所有的業(yè)務(wù)都離不開這幾個(gè)判斷，從而導(dǎo)致if else嵌套過多。那是不是沒辦法解決了？答案肯定不是的。

上面的代碼我是用java寫的，對于java程序員來說，空值判斷簡直使人很沮喪，讓人身心疲憊。上面的代碼每次回調(diào)都要判斷一次listener是否為空，又要判斷用戶傳入的ShareItem是否為空，還要判斷ShareItem里面的字段是否為空......

對于這種情況，我采用的方法很簡單：接口分層。

減少 if else 方法一：接口分層

所謂接口分層指的是：把接口分為外部和內(nèi)部接口，所有空值判斷放在外部接口完成，只處理一次；而內(nèi)部接口傳入的變量由外部接口保證不為空，從而減少空值判斷。

來，看代碼更加直觀：

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和內(nèi)部接口shareImpl，ShareItem和ShareListener的判斷都放在share里完成，那么shareImpl就減少了if else的嵌套了，相當(dāng)于把if else分?jǐn)偭恕＿@樣一來，代碼的可讀性好很多，嵌套也不超過3層了。

但可以看到，shareImpl里還是包含分享類型的判斷，也即業(yè)務(wù)判斷，我們都清楚產(chǎn)品經(jīng)理的腦洞有多大了，分享的類型隨時(shí)會改變或添加。嗯說到這里相信大家都想到用多態(tài)了。多態(tài)不但能應(yīng)付業(yè)務(wù)改變的情況，也可以用來減少if else的嵌套。

減少 if else 方法二：多態(tài)

利用多態(tài)，每種業(yè)務(wù)單獨(dú)處理，在接口不再做任何業(yè)務(wù)判斷。把ShareItem抽象出來，作為基礎(chǔ)類，然后針對每種業(yè)務(wù)各自實(shí)現(xiàn)其子類：

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
    }
}

（注意：上面每個(gè)子類的構(gòu)造方法還對每個(gè)字段做了空值處理，為空的話，賦值default，這樣如果用戶傳了空值，在調(diào)試就會發(fā)現(xiàn)問題。）

實(shí)現(xiàn)了多態(tài)后，分享接口的就簡潔多了：

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);
}

嘻嘻，怎樣，內(nèi)部接口一個(gè)if else都沒了，是不是很酷~ 如果這個(gè)分享功能是自己App里面的功能，不是第三方SDK，到這里已經(jīng)沒問題了。但如果是第三方分享SDK的功能的話，這樣暴露給用戶的類增加了很多（各ShareItem的子類，相當(dāng)于把if else拋給用戶了），用戶的接入成本提高，違背了“迪米特原則”了。

處理這種情況也很簡單，再次封裝一層即可。把ShareItem的子類的訪問權(quán)限降低，在暴露給用戶的主類里定義幾個(gè)方法，在內(nèi)部幫助用戶創(chuàng)建具體的分享類型，這樣用戶就無需知道具體的類了：

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);
}

或者有人會說，這樣用戶也需額外了解多幾個(gè)方法。我個(gè)人覺得讓用戶了解多幾個(gè)方法好過了解多幾個(gè)類，而已方法名一看就能知道意圖，成本還是挺小，是可以接受的。

其實(shí)這種情況，更多人想到的是使用工廠模式。嗯，工廠模式能解決這個(gè)問題（其實(shí)也需要用戶額外了解多幾個(gè)type類型），但工廠模式難免又引入分支，我們可以用Map消除分支。

減少 if else 方法三：使用Map替代分支語句

把所有分享類型預(yù)先緩存在Map里，那么就可以直接get獲取具體類型，消除分支：

private Map<Integer, Class<? extends ShareItem>> 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(); // 返回默認(rèn)實(shí)現(xiàn)，不要返回null
    } 
}

這種方式跟上面分為幾個(gè)方法的方式各有利弊，看大家取舍了~

寫在最后

講到這里大家有沒收獲呢？總結(jié)下減少if else的方法：

  • 把接口分為外部和內(nèi)部接口，所有空值判斷放在外部接口完成；而內(nèi)部接口傳入的變量由外部接口保證不為空，從而減少空值判斷。

  • 利用多態(tài)，把業(yè)務(wù)判斷消除，各子類分別關(guān)注自己的實(shí)現(xiàn)，并實(shí)現(xiàn)子類的創(chuàng)建方法，避免用戶了解過多的類。

  • 把分支狀態(tài)信息預(yù)先緩存在Map里，直接get獲取具體值，消除分支。

好了，到此就介紹完了，希望大家以后寫代碼能注意，有則避之，無則加勉。希望大家寫的代碼越來越簡潔~

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 寫在前面 不知大家有沒遇到過像“橫放著的金字塔”一樣的if else嵌套： 我并沒夸大其詞，我是真的遇到過了！嵌套...
    安卓大叔閱讀 39,022評論 33贊 187
  • 第一部分 HTML&CSS整理答案 1. 什么是HTML5？ 答：HTML5是最新的HTML標(biāo)準(zhǔn)。 注意：講述HT...
    kismetajun閱讀 28,817評論 1贊 45
  • 你家里人和你身邊的朋友告訴你：哎呀，你學(xué)文（理）不合適啦，不如學(xué)理（文）吧—— 不乏有這種自認(rèn)為很有經(jīng)驗(yàn)給你指明前...
    叉叉叉燒包_閱讀 628評論 1贊 2
  • 今天陽光很好，云也很漂亮，還十分幸運(yùn)的遇到了兩位非常優(yōu)秀的班主任。 作為即將上崗的老師，總是對即將到來的教...
    玻璃晴朗_e404閱讀 461評論 0贊 0
  • 哈哈，這是第三幅的完整的板繪～ 其實(shí)是和上一幅同一個(gè)畫風(fēng)，但是不知道為什么畫的畫的，有點(diǎn)點(diǎn)的不同了 但是還是很喜歡...
    Zola大嶼閱讀 312評論 0贊 1

友情鏈接更多精彩內(nèi)容