接手了個(gè)項(xiàng)目，被if..else搞懵逼了
背景
領(lǐng)導(dǎo)：“這個(gè)項(xiàng)目，今后就給你維護(hù)了啊，仔細(xì)點(diǎn)?！?小貓：“好，沒問題”。 可當(dāng)滿懷信心的小貓打開項(xiàng)目工程包翻看一些代碼之后，瞬間懵逼沒了信心。
是這樣的：
還是這樣的：
平級(jí)的if else密密麻麻就算了，但是深套五六層的if else甚至七八層的真的是讓人摸不著北。
開啟優(yōu)化
那么就上面小貓遇到的這種情況，面對(duì)著幾代程序員精心堆積的屎山，試問閣下該如何應(yīng)對(duì)？不慌，老貓羅列了以下解決方案，如果各位還有比較好的優(yōu)化方法也歡迎留言。
我們對(duì)著上述目錄從簡(jiǎn)單的開始介紹吧：
1.提前return法
當(dāng)我們遇到空對(duì)象或者有部分滿足條件之后才能執(zhí)行的時(shí)候，不要只想著正向邏輯，其實(shí)可以逆向思維，把不滿足條件的優(yōu)先排除掉。這樣可以有效避免if else的深嵌套。 優(yōu)化前代碼：
if(condition){
//doSomething
}else{
}
return;優(yōu)化后如下：
if(!condition){
return;
}2.能省則省，規(guī)避最后的else
原來的代碼：
public Result addUser() {
if (StrUtil.equals(userStatus, "online")) {
return doStep1();
} else {
return doStep2();
}
// else 后面沒有其他業(yè)務(wù)時(shí)，可省略最后的else，使代碼簡(jiǎn)潔
}優(yōu)化后的代碼:
public Result addUser() {
if (StrUtil.equals(userStatus, "online")) {
return doStep1();
}
return doStep2();
}當(dāng)然這里面要注意的點(diǎn)是，一定要確認(rèn)是最后的else，并沒有其他的業(yè)務(wù)邏輯。
3.三目運(yùn)算符
還是基于上面的代碼，如果只有兩種業(yè)務(wù)的話，其實(shí)在一個(gè)方法里面直接用三目運(yùn)算法進(jìn)行執(zhí)行即可。如下改造：
public Result addUser() {
return StrUtil.equals(userStatus, "online")) ?doStep1() : doStep2();
}一個(gè)方法一行代碼搞定。
4.使用optional
很多業(yè)務(wù)場(chǎng)景下，其實(shí)我們寫if 是為了判空，自從java8之后其實(shí)多了一個(gè)Optional神器，Optional 是個(gè)容器，它可以保存類型 T 的值，或者僅僅保存null。Optional 提供了很多方法，這樣我們就不用顯式進(jìn)行空值檢測(cè)。Optional 類的引入很好的解決空指針異常。我們看下下面的優(yōu)化方式： 代碼優(yōu)化前：
if (user == null) {
throw new Exception("未查詢到用戶信息");
}
if (user != null) {
update(user); // 執(zhí)行方法調(diào)用
}
代碼優(yōu)化后：
Optional.ofNullable(user).orElseThrow(() -> new Exception("未查詢到用戶信息"));
Optional.ofNullable(user).ifPresent(user -> update(user));隱式調(diào)用相當(dāng)優(yōu)雅。
5.設(shè)計(jì)模式優(yōu)化法
設(shè)計(jì)模式優(yōu)化法其實(shí)也是針對(duì)不同的場(chǎng)景使用不同的設(shè)計(jì)模式從而簡(jiǎn)化多余的if else。
(1) 第一種，合理使用責(zé)任鏈模式。
我們?cè)倬唧w結(jié)合一種場(chǎng)景，比方說現(xiàn)在頁面上有新注冊(cè)的用戶，他需要提交相關(guān)的身份信息進(jìn)行認(rèn)證，此時(shí)，我們底層往往會(huì)對(duì)他提交的信息做相關(guān)的校驗(yàn)處理。 底層我們的校驗(yàn)方式（1）需要驗(yàn)證基本字非空性 （2）需要驗(yàn)證身份信息基礎(chǔ)字段合法性 （2）需要調(diào)用第三方進(jìn)行要素認(rèn)證。 原始代碼如下：
public void addUser(User user) {
// 1.非空校驗(yàn)
if (StrUtil.isBlank(user.getUsername())) {
throw new RuntimeException("用戶名為空！");
}
if (StrUtil.isBlank(user.getPassword())) {
throw new RuntimeException("密碼為空！");
}
...
// 2.格式校驗(yàn)
if (!ValidUtil.isIdCardNo(user.getIdCardNo())) {
throw new RuntimeException("身份證號(hào)格式錯(cuò)誤！");
}
if (!ValidUtil.isEmail(user.getEmail())) {
throw new RuntimeException("手機(jī)號(hào)格式錯(cuò)誤！");
}
if (!ValidUtil.isEmail(user.getEmail())) {
throw new RuntimeException("郵箱格式錯(cuò)誤！");
}
...
// 3.要四素認(rèn)證校驗(yàn)
if(!doFourStampVerify(User user)){
throw new RuntimeException("四要素認(rèn)證失??！");
}
}此處可能還有很多其他的省略的場(chǎng)景。所以單個(gè)文件中的If else可能比想象中多的多。那么我們?nèi)绾斡秘?zé)任鏈模式進(jìn)行優(yōu)化呢？ 改造代碼如下,首先定義一個(gè)處理器接口：
/**
* 處理器鏈接口
*/
public interface UserChainHandler {
void handler(User user);
}剩下不同的場(chǎng)景校驗(yàn)只要去實(shí)現(xiàn)這個(gè)接口就可以了，不過需要定義好順序
@Component
@Order(1) // 指定注入順序
public class UserParamNullValidChainHandler implements UserChainHandler {
@Override
public void handler(User user) {
// 1.非空校驗(yàn)
if (StrUtil.isBlank(user.getUsername())) {
throw new RuntimeException("用戶名為空！");
}
if (StrUtil.isBlank(user.getPassword())) {
throw new RuntimeException("密碼為空！");
}
}
@Component
@Order(1) // 指定注入順序
public class UserParamNullValidChainHandler implements UserChainHandler {
@Override
public void handler(User user) {
// 1.非空校驗(yàn)
if (StrUtil.isBlank(user.getUsername())) {
throw new RuntimeException("用戶名為空！");
}
...
}
/**
* 格式校驗(yàn)處理器
*/
@Component
@Order(2) // 指定注入順序
public class UserParamFormatValidChainHandler implements UserChainHandler {
@Override
public void handler(User user) {
// 2.格式校驗(yàn)
if (!ValidUtil.isIdCardNo(user.getIdCardNo())) {
throw new RuntimeException("身份證號(hào)格式錯(cuò)誤！");
}
...
}
/**
* 四要素處理器
*/
@Component
@Order(3) // 指定注入順序
public class FourElementVerifyChainHandler implements UserChainHandler {
@Override
public void handler(User user) {
// 2.格式校驗(yàn)
if (!doFourStampVerify(User user)) {
throw new RuntimeException("四要素認(rèn)證失?。?);
}
}//進(jìn)行組裝
@Component
@RequiredArgsConstructor
public class UserChainContext {
private final List<UserChainHandler> userChainHandlerList; // 自動(dòng)注入責(zé)任鏈處理器
/**
* 責(zé)任鏈組件執(zhí)行
*
* @param requestParam 請(qǐng)求參數(shù)
*/
public void handler(User user) {
// 此處根據(jù) Ordered 實(shí)際值進(jìn)行排序處理
userChainHandlerList.forEach(x -> x.handler(user));
}
}最終咱們的原來的add方法進(jìn)行這樣調(diào)用就好了：
public void addUser(User user) {
// 執(zhí)行責(zé)任鏈
userChainContext.handler(user);
}(2) 第二種，合理使用策略模式+工廠模式。
假設(shè)我們遇到這樣一個(gè)場(chǎng)景，我們目前底層是一個(gè)會(huì)員系統(tǒng)，目前系統(tǒng)需要計(jì)算各種會(huì)員套餐的價(jià)格，然后套餐的具體模式主要是由上層系統(tǒng)傳遞指定給我們。如果只關(guān)注業(yè)務(wù)直接擼代碼的話，應(yīng)該是如下。
public Result calcPrice(CalcPriceParam calcPriceParam){
//判斷對(duì)應(yīng)的計(jì)算價(jià)格的場(chǎng)景
Integer type = judgeType(calcPriceParam);
//根據(jù)場(chǎng)景調(diào)用不同的方法 ,建議更好的編碼習(xí)慣是把type改成枚舉類型哈～
if(type == 1){
return calcPriceForTypeOne();
}
if(type == 2){
return calcPriceForTypeTwo();
}
if(type == 3){
return calcPriceForTypeThree();
}
.....
if(typr == 10){
return calcPriceForTypeTen();
}
}顯而易見隨著會(huì)員價(jià)格場(chǎng)景套餐越來越多，我們的if也會(huì)越來越多。 但是如果使用策略模式的話，我們可以做到如下：
public interface Strategy {
Result calcPrice(CalcPriceParam calcPriceParam);
int getBizType();
}
@Service
public Class firstStragy implement Strategy {
Result calcPrice(CalcPriceParam calcPriceParam) {
....
return result;
}
int getBizType() {
return 1;
}
}
public Class secondStragy implement Strategy {
Result calcPrice(CalcPriceParam calcPriceParam) {
....
return result;
}
int getBizType() {
return 2;
}
}
@Service
public class StrategyContext{
Map<Integer,CalcPriceInterface> strategyContextMap = new HashMap<>();
//注入對(duì)應(yīng)的策略類
@Autowired
Strategy[] strategys;
@PostConstruct
public void setStrategyContextMap(){
for(Stragegy stragegy:strategys){
strategyContextMap.put(stragegy.getCode,stragegy);
}
}
//根據(jù)場(chǎng)景調(diào)用不同的方法
public Result calcPrice(CalcPriceParam calcPriceParam){
Integer type = judgeType(calcPriceParam);
CalcPriceInterface calcPriceInstance = strategyContextMap.get(type);
return calcPriceInstance.calcPrice(calcPriceParam);
}
}這樣一來，咱們上面的第一個(gè)方法中的If else的實(shí)現(xiàn)將會(huì)變得很簡(jiǎn)單，如下：
@Autowired
StrategyContext strategyContext;
public Result calcPrice(CalcPriceParam calcPriceParam){
strategyContext.calcPrice(calcPriceParam);
}這樣即使新增新的計(jì)算模式，我們只需去實(shí)現(xiàn)Strategy接口并且重寫里面兩個(gè)方法即可完成后續(xù)業(yè)務(wù)的拓展。代碼優(yōu)雅簡(jiǎn)單，可維護(hù)性強(qiáng)。 以上就是用設(shè)計(jì)模式針對(duì)大量if else進(jìn)行改造。
6.表驅(qū)動(dòng)法
這種方式個(gè)人覺得有點(diǎn)像策略模式，但是又不需要單獨(dú)抽出相關(guān)類去承載注冊(cè)方法，而是簡(jiǎn)單地將方法通過函數(shù)式的方式放到Map中，等到需要使用的時(shí)候再進(jìn)行調(diào)用。 原始爛代碼，我們還是參考上述會(huì)員費(fèi)用金額計(jì)算的場(chǎng)景。我們可以進(jìn)行如下方式優(yōu)化：
Map<String, Function<?> action> actionMap = new HashMap<>();
action.put("type1",() -> {calcPriceForTypeOne()});
action.put("type2",() -> {calcPriceForTypeTwo()});
action.put("type3",() -> {calcPriceForTypeThree()});
...
// 使用
actionMap.get(action).apply();當(dāng)然如果想要再優(yōu)化得好一些的話，可以進(jìn)行接口抽取，然后進(jìn)行實(shí)現(xiàn)，在此不展開，留下給小伙伴們思考一下。
7.其他場(chǎng)景靈活運(yùn)用，干掉if else
我們?cè)倩氐街靶∝堄龅降哪莾蓚€(gè)代碼截圖，其實(shí)我們可以看到有個(gè)大量if else并排的代碼其實(shí)主要是想要比較相關(guān)的屬性有沒有發(fā)生變化，如果發(fā)生變化，那么則返回false，沒有變化則返回true。其實(shí)我們想想是不是可以通過重寫LogisticDO這個(gè)對(duì)象的equals方法來進(jìn)行實(shí)現(xiàn)呢？這樣是不是也規(guī)避了大量的if else。
還有其他一些當(dāng)然也是根據(jù)具體場(chǎng)景來解決，比方說，我需要根據(jù)不同的type類型，進(jìn)行獲取不同的描述信息，那么此時(shí)我們是不是可以使用enum去維護(hù)呢？ 如下：
if(status.equals(1)){
return "訂單未支付";
}else if(status.equals(2)){
return "訂單已支付"
}else if(status.equals(3)){
return "訂單已發(fā)貨"
}
.....優(yōu)化后：
@Getter
@AllArgsConstructor
public enum OrderStatusEnum {
UN_PAID("1","訂單未支付"),
PAIDED("2","訂單已支付"),
SENDED("3","訂單已發(fā)貨"),
.....;
private String status;
private String statusDes;
static OrderStatusEnum of(String status) {
for (OrderStatusEnum statusEnum : OrderStatusEnum.values()) {
if (statusEnum.getStatus().equals(status)) {
return statusEnum;
}
}
return null;
}
}
String orderStatusDes = OrderStatusEnum.of(orderStatus).getStatusDes();等等還有其他一些，由于這些優(yōu)化個(gè)人認(rèn)為是沒法標(biāo)準(zhǔn)化的優(yōu)化原則，不同的業(yè)務(wù)場(chǎng)景都不同，所以在此，老貓不將其放在通用優(yōu)化中，認(rèn)為這個(gè)是其他優(yōu)化方式。
結(jié)束語
之前在某個(gè)技術(shù)論壇上看到大家在爭(zhēng)論這么一個(gè)問題“如何避免將維護(hù)的項(xiàng)目發(fā)展成屎山？”大家發(fā)言踴躍。有說前期做好設(shè)計(jì)，有人說代碼質(zhì)量需要高一些，合理場(chǎng)景套用一些設(shè)計(jì)模式等等。 不過老貓認(rèn)為項(xiàng)目無法避免發(fā)展成屎山，只是快慢而已，我也認(rèn)為項(xiàng)目無法避免發(fā)展成“屎山”。其原因有三點(diǎn)：
- 項(xiàng)目代碼維護(hù)者經(jīng)過好幾輪，每次開發(fā)技術(shù)水平參差不齊，代碼風(fēng)格也不同。
- 項(xiàng)目迭代中途有很多突發(fā)狀況，比方說為了解決Hotfix臨時(shí)上線，為了趕項(xiàng)目臨時(shí)上線，大家為了趕工完成業(yè)務(wù)需求，代碼質(zhì)量可能就可想而知了。
- 雖然經(jīng)過好幾輪研發(fā)之手，有的研發(fā)害怕改出業(yè)務(wù)問題，所以選擇繼續(xù)堆屎山。
說了這么多，其實(shí)老貓最終想表達(dá)的是，雖然項(xiàng)目會(huì)最終淪為屎山，但是作為一個(gè)有追求的研發(fā)，我們就應(yīng)當(dāng)從每個(gè)小的if else著手，至少讓當(dāng)前這個(gè)項(xiàng)目在你維護(hù)期間，讓其發(fā)展成屎山的速度變慢一些，或者能替之前的老前輩還掉一些技術(shù)債才是最好的，各位小伙伴你們覺得呢？
