<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          減少代碼中該死的 if else 嵌套,讓代碼更簡潔

          共 9650字,需瀏覽 20分鐘

           ·

          2021-06-22 12:52

          不知大家有沒遇到過像“橫放著的金字塔”一樣的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í),是不是覺得很簡單,稍動(dòng)下腦就可以動(dòng)手了:

          先定義分享的類型、分享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ù)本身。所以我們很有必要避免寫出多分支嵌套的語句。好的,我們來分析下上面的代碼多分支的原因:


          1. 空值判斷
          2. 業(yè)務(wù)判斷
          3. 狀態(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獲取具體值,消除分支。


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


          到這里就結(jié)束啦。
          瀏覽 93
          點(diǎn)贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評論
          圖片
          表情
          推薦
          點(diǎn)贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  免费操B| 天天弄天天模 | 爱干av麻豆 | 热久久国产精品视频 | 俺也来欧美精品 |