前段時間在閱讀別人所寫的代碼的時候 , 發現其中一些業務相關的方法體內 , 出現了比較多的if-else
語句多層嵌套的狀況 . 首先我我的不是不提倡寫if-else
語句 , 不得不說 , 不少時候 , 在寫某些邏輯 使用if-else
去作判斷 , 代碼看起來仍是十分直觀的 , 可是若是濫用if-else
, 造成多層嵌套或者造成, 其中每一個case 還包含了大量的邏輯 , 此時從可讀性來講 , 使用if-else
就有點得不償失了 . 並且某些時候 , 可能並不需這麼多的if-else
, 或者是可使用其餘編碼方式從而達到減小的if-else
的效果 .java
減小if-else
的使用的方式有不少 , 例如設計模式層面的策略模式或者是責任鏈模式 . 而這裏跟你們分享一下一些我的在平常編碼過程當中常常用到的 , 比較簡單的 、從編碼習慣層面上的方式 , 去一些減小沒必要要if-else
使用 . 因爲本人只是一個小菜鳥 , 若是有寫得不對的地方 , 懇請批評指正 .數據庫
首先展現一段代碼示例 :express
if (condition1) { if (condition2) { return getSomething(); } else { return 0; } } else { return 0; } 複製代碼
修改後的代碼以下 :設計模式
//這裏最好對這個flag所判斷的邏輯補充註釋進行描述 boolean flag = !condition1 || (condition1 && !condition2) if(flag) { return 0; } if (condition1 && condition2) { return getSomething(); } 複製代碼
若是存在已知在某些條件下 , 須要返回固定值的邏輯 , 能夠將這部分邏輯抽取爲一個獨立的 if-else block
, 並置於其餘if-else block
的前面 , 當符合該特定條件時 , 直接提早 return
固定值 . 這種方式最直接的效果就是下降if-else
的嵌套數量 .數組
先上例子 , 這裏以一個業務場景爲例 :markdown
查詢某條評論的圖片URL列表 (若是有 , 評論的圖片url列表以JSON數組字符串格式保存在評論表中)mybatis
修改前的代碼以下 :框架
Comment comment = getById(commentId); if (Objects.isNull(comment)) { throw new RuntimeException("評論不存在或已被刪除"); } String imgListStr = comment.getImgList(); if(StringUtils.isEmpty(imgListStr)) { return null; } return JSON.parseArray(imgListStr, String.class); 複製代碼
修改後 :工具
Comment comment = getById(commentId); if (Objects.isNull(comment)) { throw new RuntimeException("評論不存在或已被刪除"); } String imgListStr = comment.getImgList(); return StringUtils.isEmpty(imgListStr)) ? null : JSON.parseArray(imgListStr, String.class); 複製代碼
在編寫業務代碼過程當中 , 若是須要對某些特定的條件進行判斷 , 且當條件不知足時須要拋出異常 . 對於這種場景 , 除了使用上面三目運算符的示例當中的if
方式 , 還能夠經過使用Spring Framework 給咱們提供的 Assert
工具類進行 .編碼
其中經常使用的API 有 :
expressio == false
時 , 會拋出異常 , 異常的message
則爲第二個入參 ;object == null
時 , 會拋出異常;null
或者集合元素爲空時 , 會拋出異常 .還有其餘較多方法 , 能夠直接看源碼的解析 , 固然實際上isTrue()
已經夠用了 , 若是須要更加的語義化 , 可使用對應的API .
修改前代碼 :
if (Objects.isNull(comment)) { throw new RuntimeException("評論不存在或已被刪除"); } 複製代碼
修改後代碼 :
Assert.isTrue(Objects.nonNull(comment),"評論不存在或已被刪除"); Assert.notNull(comment,"評論不存在或已被刪除"); 複製代碼
目前Assert工具方法只能拋出單一一種異常 java.lang.IllegalArgumentException
, 若是須要自定義所拋出的異常 , 則該方式不適用 .
Optional是 java8 的新特性 , 至關於一個對象的容器 , 主要用於對象的null
值校驗 , 以及在進行校驗後可鏈式地進行後續操做 , 如 : 拋出異常、null
替換 等 .
其中我我的比較經常使用的幾個方法爲 :
null
時 ,返回入參的對象 .null
時 , 返回Supplier
提供的值 ;null
時 , 拋出supplier
提供的自定義異常代碼示例 :
Message message1 = Optional.ofNullable(getById(messageId)) .orElseThrow(() -> new RuntimeException("消息不存在!")); Message message2 = Optional.ofNullable(getById(messageId)) .orElse(new Message()); Message message3 = Optional.ofNullable(getById(messageId)) .orElseGet(Message::new); 複製代碼
因爲我平常須要的進行空值判斷的比較多的場景是從數據庫查詢數據完畢時 , 須要查詢結果進行空值判斷 . 因爲我所在的公司使用的持久層框架是mybatis , 不像Spirng Boot 2.x 默認版本的JPA 那樣DAO層方法支持返回值爲Optional , 因此這裏若是須要使用Optional , 只能手動去使用上面列舉的第一個方法對查詢結果進行包裝 .
固然 , IDEA其實已經給咱們提供了該包裝方式的熱鍵了 , 以下圖所示 :
我的的一些減小if-else
編碼習慣分享就這裏了 , 這幾種方式裏面 , 我我的以爲效果最明顯的仍是第一種 提早return , 不少時候 , 提早return 也能夠很好下降一段代碼的複雜度 .
固然若是必需要使用大量的if-else
去控制邏輯時 , 在每一個condition 標明一下注釋仍是一個挺不錯的習慣 .