淺談代碼優(yōu)化與過(guò)度設(shè)計(jì)

阿里妹導(dǎo)讀

本文記錄了作者從“代碼優(yōu)化”到“過(guò)度設(shè)計(jì)”的典型思考過(guò)程，這過(guò)程中涉及了很多Java的語(yǔ)法糖及設(shè)計(jì)模式的東西，很典型，能啟發(fā)思考，遂記錄下來(lái)。

有一天Review師妹的代碼，看到一行很難看的代碼，畢竟師妹剛開(kāi)始轉(zhuǎn)JAVA，一些書(shū)寫小習(xí)慣還是要養(yǎng)成，所以錙銖必較還是有必要的，于是給出了一些優(yōu)化思路的建議，以及為什么要這么做。建議完后，我并沒(méi)有停下”追求極致“的腳步，隨著不斷的思考，發(fā)現(xiàn)這段代碼的優(yōu)化慢慢變得五花八門起來(lái)了，完成了一次“代碼優(yōu)化”到“過(guò)度設(shè)計(jì)”的典型思考過(guò)程，這過(guò)程中涉及了很多Java的語(yǔ)法糖及設(shè)計(jì)模式的東西，很典型，能啟發(fā)思考，遂記錄下來(lái)。

一切的開(kāi)始

起初是一段很簡(jiǎn)單的代碼，開(kāi)始僅僅是將外域的一些標(biāo)識(shí)符轉(zhuǎn)換為域內(nèi)的標(biāo)識(shí)符。

public Integer parseSaleType(String saleTypeStr){
  if(saleTypeStr == null || saleTypeStr.equals("")){
    return null;
  }
  if(saleTypeStr.equals("JX")){
    return 1;
  }
  return null;
}

邏輯上很簡(jiǎn)單，實(shí)現(xiàn)的邏輯看上去也沒(méi)啥大問(wèn)題，基本學(xué)校的老師也是這么教的。

語(yǔ)法規(guī)范

但是嘛，不好看也容易犯錯(cuò)誤，雞蛋里挑骨頭也得挑，于是給出了幾個(gè)寫代碼的建議：

有函數(shù)式方法的盡量用

//saleTypeStr == null
Objects.isNull(saleTypeStr)

首先呢，雖然由于判斷null這么寫不會(huì)報(bào)錯(cuò)，但是按照常量寫==前面的要求，應(yīng)該倒過(guò)來(lái)寫。另外，這種有JDK原生函數(shù)式的判斷方法，還是優(yōu)先使用函數(shù)式的寫法，一來(lái)是有方法名比較直觀，另外也是方便之后熟練使用Lamada，別寫出 .filter(x -> null == x) 這樣的寫法，還是 .filter(Objects::isNull) 更可讀些。

判斷字符串為空不要自己寫

容易漏邏輯，盡量使用現(xiàn)成的方法

//if(saleTypeStr == null || saleTypeStr.equals(""))
if(StringUtils.isBlank(saleTypeStr))

雖然原方法里無(wú)論判不判斷空字符或者空格字符都不會(huì)影響最終方法的表征，但是從第一行想表達(dá)的判斷“字符串是不是為空”這件事來(lái)看，這行并不能判斷“空格字符”存在的情況，所以詞不達(dá)意，另外也趁機(jī)強(qiáng)化記憶下isBlank和isEmpty的區(qū)別。 org.apache.commons.lang3里有很多工具類，方法比較成熟邏輯也比較完整。 同理org.apache.commons.collections4.CollectionUtils還有一堆集合操作的工具。

equals判定，常量寫前面

//if(saleTypeStr.equals("JX"))
if("JX".equals(saleTypeStr))

雖然前面判斷過(guò)null，所以這里并不會(huì)報(bào)空指針，但是但凡之后書(shū)寫前面漏了，這里就開(kāi)始報(bào)錯(cuò)了。

少用魔法值，定義常量

private static final String JX_SALE_TYPE_STR = "JX";
private static final Integer JX_SALE_TYPE_INT = 1;

但凡同一個(gè)魔法值在多處用，就怕漏改，所以收束定義在常量下，至少能保證全局引用的統(tǒng)一性。

無(wú)狀態(tài)方法，可選擇定義為類靜態(tài)

//public Integer parseSaleType(String saleTypeStr)
public static Integer parseSaleType(String saleTypeStr)

方法本身跟所在類的實(shí)例對(duì)象狀態(tài)無(wú)關(guān)，且不會(huì)誘發(fā)線程安全問(wèn)題，故符合被定義為static的條件，可先于對(duì)象創(chuàng)建在方法區(qū)，防止每個(gè)對(duì)象創(chuàng)建一次的時(shí)候，堆內(nèi)存創(chuàng)建一次。

邏輯簡(jiǎn)化

語(yǔ)法的問(wèn)題強(qiáng)調(diào)完，就得再琢磨琢磨這段邏輯需不需要這么多代碼來(lái)表述了，乍眼一看沒(méi)問(wèn)題，但其實(shí)沒(méi)必要寫這么多。

明確主體邏輯

判斷入?yún)⒂行?-> 處理核心邏輯 -> 缺省返回，其實(shí)這個(gè)方法的構(gòu)建思路是非常標(biāo)準(zhǔn)且合乎常理的，思考習(xí)慣很好，只是在這個(gè)簡(jiǎn)單的方法場(chǎng)景不免邏輯有些冗余。 其實(shí)再看這個(gè)方法，最核心的邏輯就是把字符串對(duì)應(yīng)到數(shù)字上，其他不命中的情況返回null就可以了，那么簡(jiǎn)化邏輯后，為空判定其實(shí)可以去掉，直接變?yōu)椋?

private static final String JX_SALE_TYPE_STR = "JX";
private static final Integer JX_SALE_TYPE_INT = 1;


public static Integer parseSaleType(String saleTypeStr){
  if(JX_SALE_TYPE_STR.equals(saleTypeStr)){
    return JX_SALE_TYPE_INT;
  }
  return null;
}

語(yǔ)法簡(jiǎn)化：三元運(yùn)算符

再仔細(xì)看下場(chǎng)景有沒(méi)有成熟的范式，【布爾式+返回值+非此即彼】，三元運(yùn)算符可堪一用。

public static Integer parseSaleType(String saleTypeStr){
  return JX_SALE_TYPE_STR.equals(saleTypeStr) ? JX_SALE_TYPE_INT : null;
}

語(yǔ)法簡(jiǎn)化：Optional

這個(gè)場(chǎng)景范式也滿足，【可能為空，有后續(xù)處理，有條件，有缺省值】，Optional也算完美契合。

public static Integer parseSaleType(String saleTypeStr){
  Optional.ofNullable(saleTypeStr).filter(JX_SALE_TYPE_STR::equals).map(o -> JX_SALE_TYPE_INT).orElse(null);
}

方法獨(dú)立存在的必要性討論

其實(shí)語(yǔ)法簡(jiǎn)化到三元運(yùn)算符和Optional這一步，如果一個(gè)方法體內(nèi)只有這一行，這個(gè)方法獨(dú)立存在的必要性的就開(kāi)始存疑了，如果所有的轉(zhuǎn)換流程都能收束在工程中的某個(gè)環(huán)節(jié)上，且保證這個(gè)方法的引用僅存在一處，那么這一行代碼其實(shí)放在主干代碼上更好，防止來(lái)回跳轉(zhuǎn)的代碼閱讀障礙，當(dāng)然這也僅僅是在現(xiàn)狀下的討論，如果存在且不僅限于以下幾種狀況時(shí)還得獨(dú)立出來(lái)：

未來(lái)除了一種邏輯分支外，還會(huì)擴(kuò)展其他分支，并且有被擴(kuò)展的可能；

雖然還是一種邏輯分支，但是判斷的內(nèi)容變長(zhǎng)了，跟上下文和調(diào)用狀態(tài)有關(guān)；

雖然還是一種邏輯分支，但是邏輯總在調(diào)整；

一處定義，多點(diǎn)引用；

繼續(xù)拓展：定義枚舉

“如無(wú)必要，勿增實(shí)體” 假如這個(gè)傳入的字符其實(shí)還有很多種，返回的映射也有很多種的時(shí)候，其實(shí)在這里繼續(xù)寫一堆常量定義就很不理智了。

值枚舉構(gòu)建

考慮繼續(xù)將入?yún)⒌乃锌赡芎统鰠⒌乃锌赡?，可以?gòu)建為兩組枚舉值，這樣所有的同簇常量就被放到一起了。

public enum SaleTypeStrEnum{
  JX,
  // OTHERS
  ;
}


@AllArgsConstructor
@Getter
public enum SaleTypeIntEnum{
  JX(1),
  // OTHERS
  ;
  private Integer code;
}

但是這個(gè)枚舉功能并不完善，因?yàn)閺娜雲(yún)⒂成錇镾aleTypeStrEnum，依然需要一段轉(zhuǎn)換的邏輯，需要用到 SaleTypeStrEnum::name 來(lái)判定傳參命中了哪個(gè)，所以這個(gè)邏輯不應(yīng)該放在枚舉外，繼續(xù)補(bǔ)充：

public enum SaleTypeStrEnum{
  JX,
  // OTHERS 
  ;
  public static SaleTypeStrEnum getByName(String saleTypeStr){
    for (SaleTypeStrEnum value : SaleTypeStrEnum.values()) {
      if(value.name().equals(saleTypeStr)){
        return value;
      }
    }
    return null;
  }
}

方法有了，但是每次傳進(jìn)來(lái)值都要遍歷整個(gè)枚舉，O(n)效率太低了，還是老規(guī)矩，空間換時(shí)間。

public enum SaleTypeStrEnum{
  JX,
  // OTHERS
  ;
  
  /**
    * 預(yù)熱轉(zhuǎn)換關(guān)系到內(nèi)存
    */
  private static Map NAME_MAP = Arrays.stream(SaleTypeStrEnum.values()).collect(Collectors.toMap(SaleTypeStrEnum::name, Function.identity()));
    
  public static SaleTypeStrEnum getByName(String saleTypeStr){
    return NAME_MAP.get(saleTypeStr);
  }
}

這樣每次檢索就是O(1)了，那么最終方法體內(nèi)也能使用switch管理原本的if-else

public static Integer parseSaleType(String saleTypeStr){
  switch(SaleTypeStrEnum.getByName(saleTypeStr)){
    case JX:return SaleTypeIntEnum.JX.getCode();
    // OTHERS
    default:return null;
  }
}

關(guān)系枚舉構(gòu)建

再仔細(xì)思考下，其實(shí)這里在描述的內(nèi)容，無(wú)論是哪個(gè)枚舉描述的內(nèi)容都是同一件事物，方法本身就是描述兩個(gè)不同編碼的轉(zhuǎn)換關(guān)系，且轉(zhuǎn)換關(guān)系本身就是單向的，且映射路徑極度簡(jiǎn)單，所以簡(jiǎn)單化一點(diǎn)，可以直接構(gòu)建轉(zhuǎn)換關(guān)系枚舉?。

@Getter
@AllArgsConstructor
public enum SaleTypeRelEnum {
  // 不在分別定義兩類變量，而是直接定義變量映射關(guān)系
  JX("JX", 1),
  // OTHERS
  ;
  private String fromCode;
  private Integer toCode;


  private static Map FROM_CODE_MAP = Arrays.stream(SaleTypeRelEnum.values()).collect(Collectors.toMap(SaleTypeRelEnum::getFromCode, Function.identity()));


  public static SaleTypeRelEnum get(String saleTypeStr){
    return FROM_CODE_MAP.get(saleTypeStr);
  }


  public static Integer parseCode(String saleTypeStr){
    return Optional.ofNullable(SaleTypeRelEnum.get(saleTypeStr)).map(SaleTypeRelEnum::getToCode).orElse(null);
  }
}

如果將轉(zhuǎn)關(guān)系作為枚舉，那么從職責(zé)上劃分，轉(zhuǎn)換這個(gè)動(dòng)作應(yīng)該是封閉在枚舉內(nèi)的固有行為，而不該暴露在外，故原來(lái)對(duì)方法的引用其實(shí)應(yīng)該轉(zhuǎn)為對(duì)關(guān)系枚舉中 SaleTypeEnum::parseCode 方法的引用，O(1)檢索且封閉性良好，同時(shí)支持更多簡(jiǎn)單單向映射關(guān)系的管理，要是以后出現(xiàn)的新場(chǎng)景都是這種關(guān)系，那夠扛很久嘞。

繼續(xù)拓展：設(shè)計(jì)模式

枚舉的前提還是基于無(wú)狀態(tài)前提，如果轉(zhuǎn)換的的映射關(guān)系不再單純，變得復(fù)雜，枚舉的簡(jiǎn)單映射管理就不work了。? “萬(wàn)事不決，上設(shè)計(jì)模式”? 哎~就是玩兒~

策略模式-簡(jiǎn)單實(shí)現(xiàn)

首先，依然將傳入的字符串作為路由依據(jù)，但是傳入的內(nèi)容為了防止有未來(lái)擴(kuò)展，所以構(gòu)造一個(gè)上下文，策略本身基于上下文來(lái)處理，借助上文定義的值枚舉做策略路由。

/**
  * 定義策略接口
  */
public interface SaleTypeParseStrategy{
  Integer parse(SaleTypeParseContext saleTypeParseContext);
}


/**
  * 策略實(shí)現(xiàn)
  */
public class JxSaleTypeParseStrategy implements SaleTypeParseStrategy{
  @Override
  public Integer parse(SaleTypeParseContext saleTypeParseContext) {
    return SaleTypeIntEnum.JX.getCode();
  }
}


/**
  * 調(diào)用上下文
  */
@Data
public class SaleTypeParseContext{
  private SaleTypeStrEnum saleTypeStr;
  
  private SaleTypeParseStrategy parseStrategy;
  
  public Integer pasre(){
    return parseStrategy.parse(this);
  }
}


public static Integer parseSaleType(String saleTypeStr){
  SaleTypeStrEnum saleTypeEnum = SaleTypeStrEnum.getByName(saleTypeStr);
  SaleTypeParseContext context = new SaleTypeParseContext();
  context.setSaleTypeStr(saleTypeEnum);
  switch(saleTypeStr){
    // 策略路由
    case JX:context.setParseStrategy(new JxSaleTypeParseStrategy());break;
    // 繼續(xù)擴(kuò)展
    default:return null;
  }
  return context.parse();
}

當(dāng)然，如果是這種沒(méi)有上下文強(qiáng)依賴的策略，無(wú)論是靜態(tài)單例還是Spring單例都會(huì)是一個(gè)不錯(cuò)的選擇。SaleTypeParseContext本身可以繼續(xù)擴(kuò)展內(nèi)容和其他屬性繼續(xù)豐富參數(shù)，策略實(shí)現(xiàn)中也可以繼續(xù)針對(duì)更多參數(shù)擴(kuò)充邏輯。

策略工廠-手動(dòng)容器

策略是個(gè)好東西，但是簡(jiǎn)單實(shí)現(xiàn)下，這里依然將策略實(shí)現(xiàn)的路由過(guò)程交給了調(diào)用方來(lái)做，那么每增加一種實(shí)現(xiàn)，調(diào)用點(diǎn)還要繼續(xù)改，要是恰好有若干調(diào)用點(diǎn)就完?duì)僮恿?，并不?yōu)雅，所以搞個(gè)中間層容器工廠，解耦一下依賴。

@Component
public static class SaleTypeParseStrategyContainer{
  public final static Map STRATEGY_MAP = new HashMap<>();


  @PostConstruct
  public void init(){
    STRATEGY_MAP.put(SaleTypeStrEnum.JX, new JxSaleTypeParseStrategy());
    // 繼續(xù)拓展
  }


  public Integer parse(SaleTypeParseContext saleTypeParseContext){
    return Optional.ofNullable(STRATEGY_MAP.get(saleTypeParseContext.getSaleTypeStr())).map(strategy-> strategy.parse(saleTypeParseContext)).orElse(null);
  }
}

容器內(nèi)手動(dòng)創(chuàng)建各個(gè)策略的實(shí)現(xiàn)的單例后進(jìn)行托管，那調(diào)用方只需要去構(gòu)建上下文就好了，實(shí)際調(diào)用的方法更換為 SaleTypeParseStrategyContainer::parse，那后續(xù)無(wú)論策略如何豐富，調(diào)用方都不需要再感知這部分變化。后續(xù)出現(xiàn)了新的策略實(shí)現(xiàn)，則在工廠內(nèi)繼續(xù)追加路由表即可。

注冊(cè)與發(fā)現(xiàn)&策略工廠-Spring容器

如果考慮到策略會(huì)依賴Spring的bean和其他有狀態(tài)對(duì)象，那么這里也可以改成Spring的注入模式，同時(shí)繼續(xù)將“支持哪種情況”由托管方容器移動(dòng)至策略內(nèi)部，改成由策略實(shí)現(xiàn)自身去注冊(cè)到容器中。??

public interface SaleTypeParseStrategy{
  Integer parse(SaleTypeParseContext saleTypeParseContext);
  // 所支持的情況
  SaleTypeStrEnum support();
}


@Component
public class JxSaleTypeParseStrategy implements SaleTypeParseStrategy{
  @Override
  public Integer parse(SaleTypeParseContext saleTypeParseContext) {
    return SaleTypeIntEnum.JX.getCode();
  }
  @Override
  public SaleTypeStrEnum support() {
    return SaleTypeStrEnum.JX;
  }
}


@Component
public static class SaleTypeParseStrategyContainer{
  public final static Map STRATEGY_MAP = new HashMap<>();
  @Autowired
  private List parseStrategyList;
  
  @PostConstruct
  public void init(){
    parseStrategyList.stream().forEach(strategy-> STRATEGY_MAP.put(strategy.support(), strategy));
  }
  public Integer parse(SaleTypeParseContext saleTypeParseContext){
    return Optional.ofNullable(STRATEGY_MAP.get(saleTypeParseContext.getSaleTypeStr())).map(strategy-> strategy.parse(saleTypeParseContext)).orElse(null);
  }
}

這樣的話，連容器都不用改了，追加策略實(shí)現(xiàn)的改動(dòng)只與當(dāng)前策略有關(guān)，調(diào)用方和容器類都不需要感知了，但是缺點(diǎn)就在于如果有倆策略支持的情況相同，取到的是哪個(gè)就聽(tīng)天由命了~

注冊(cè)與發(fā)現(xiàn)&責(zé)任鏈

當(dāng)然如果不能事先知道“支持哪種情況”，只能在運(yùn)行時(shí)判斷“是否支持”，將事前判定改為運(yùn)行時(shí)判定，廣義責(zé)任鏈會(huì)是一個(gè)不錯(cuò)的選擇，把所有策略排成一排，誰(shuí)舉手說(shuō)自己能處理就誰(shuí)處理。??

public interface SaleTypeParseStrategy{
  Integer parse(SaleTypeParseContext saleTypeParseContext);
  // 用于判斷是否支持
  boolean support(SaleTypeParseContext saleTypeParseContext);
}


@Component
public class JxSaleTypeParseStrategy implements SaleTypeParseStrategy{
  @Override
  public Integer parse(SaleTypeParseContext saleTypeParseContext) {
    return SaleTypeIntEnum.JX.getCode();
  }
  @Override
  public boolean support(SaleTypeParseContext saleTypeParseContext) {
    return SaleTypeStrEnum.JX.equals(saleTypeParseContext.getSaleTypeStr());
  }
}


@Component
public static class SaleTypeParseStrategyContainer{
  @Autowired
  private List parseStrategyList;


  public Integer parse(SaleTypeParseContext saleTypeParseContext){
    return parseStrategyList.stream()
        .filter(strategy->strategy.support(saleTypeParseContext))
        .findAny()
        .map(strategy->strategy.parse(saleTypeParseContext))
        .orElse(null);
  }
}

這樣的實(shí)現(xiàn)，依然可以將改動(dòng)收束在策略本體上，修改相對(duì)集中，可以無(wú)耦地進(jìn)行擴(kuò)展。

其他拓展

以上還只是在JAVA語(yǔ)言內(nèi)去玩一些花樣，在當(dāng)前這種場(chǎng)景下肯定是有過(guò)度設(shè)計(jì)的嫌疑，7行代碼可以縮到1行，也可以擴(kuò)充到70行，所以說(shuō)嘛： “用代碼行數(shù)來(lái)考量一個(gè)程序員是不太合適滴！~”? 當(dāng)然了，也還可以繼續(xù)借助其他的中間件搞花樣，包括但不限于：

植入Diamond走走動(dòng)態(tài)配置開(kāi)關(guān)的思路；

植入QLExpress搞搞邏輯表達(dá)式的思路；

把策略實(shí)現(xiàn)改成HsfProvider走分布式調(diào)用思路；

借助一些成熟的網(wǎng)關(guān)走服務(wù)路由的的調(diào)用思路；

就不再此再過(guò)多展開(kāi)了。

總結(jié)

筆記向的內(nèi)容帖子，用于活躍思維打開(kāi)思路，沒(méi)啥高科技~

審核編輯：湯梓紅