當我看到一堆if else時，個人心裏是奔潰的

時間  2019-11-06
標籤 看到 一堆 個人 心裏 简体版
原文   原文鏈接

寫在前面


不知你們有沒遇到過像「橫放着的金字塔」同樣的if else嵌套：java

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

                   }
               }
           }
       }
   }
}複製代碼

我並沒誇大其詞，我是真的遇到過了！嵌套六、7層，一個函數幾百行，簡！直！看！死！人！程序員

if else做爲每種編程語言都不可或缺的條件語句，咱們在編程時會大量的用到。但if else通常不建議嵌套超過三層，若是一段代碼存在過多的if else嵌套，代碼的可讀性就會急速降低，後期維護難度也大大提升。因此，咱們程序員都應該儘可能避免過多的if else嵌套。下面將會談談我在工做中如何減小if else嵌套的。編程

正文

在談個人方法以前，不妨先用個例子來講明if else嵌套過多的弊端。緩存

想象下一個簡單分享的業務需求：支持分享連接、圖片、文本和圖文，分享結果回調給用戶（爲了避免跑題，這裏簡略了業務，實際複雜得多）。當接手到這麼一個業務時，是否是以爲很簡單，稍動下腦就能夠動手了：bash

先定義分享的類型、分享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了：ide

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個分支，還要改代碼，一點都不「開放-閉合」。再再若是後面項目交接給他人跟進，他人又要把本身大腦變成處理器來想每一個分支的做用，我敢確定有百分之八十的人都會吐槽代碼。函數

咱們程序員的腦力不該該花費在無止境的分支語句裏的，應該專一於業務自己。因此咱們頗有必要避免寫出多分支嵌套的語句。好的，咱們來分析下上面的代碼多分支的緣由：測試

空值判斷ui

業務判斷

狀態判斷

幾乎全部的業務都離不開這幾個判斷，從而致使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);
}複製代碼

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

其實這種狀況，更多人想到的是使用工廠模式。嗯，工廠模式能解決這個問題（其實也須要用戶額外瞭解多幾個type類型），但工廠模式不免又引入分支，咱們能夠用Map消除分支。

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

把全部分享類型預先緩存在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(); // 返回默認實現，不要返回null
   } 
}複製代碼

這種方式跟上面分爲幾個方法的方式各有利弊，看你們取捨了~

寫在最後

講到這裏你們有沒收穫呢？總結下減小if else的方法

把接口分爲外部和內部接口，全部空值判斷放在外部接口完成；而內部接口傳入的變量由外部接口保證不爲空，從而減小空值判斷。

利用多態，把業務判斷消除，各子類分別關注本身的實現，並實現子類的建立方法，避免用戶瞭解過多的類。

把分支狀態信息預先緩存在Map裏，直接get獲取具體值，消除分支。

好了，到此就介紹完了，但願你們之後寫代碼能注意，有則避之，無則加勉。但願你們寫的代碼愈來愈簡潔~

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程