阿里妹導讀

本文記錄了作者從“代碼優化”到“過度設計”的典型思考過程，這過程中涉及了很多Java的語法糖及設計模式的東西，很典型，能啟發思考，遂記錄下來。

有一天Review師妹的代碼，看到一行很難看的代碼，畢竟師妹剛開始轉JAVA，一些書寫小習慣還是要養成，所以錙銖必較還是有必要的，于是給出了一些優化思路的建議，以及為什么要這么做。建議完后，我并沒有停下”追求極致“的腳步，隨著不斷的思考，發現這段代碼的優化慢慢變得五花八門起來了，完成了一次“代碼優化”到“過度設計”的典型思考過程，這過程中涉及了很多Java的語法糖及設計模式的東西，很典型，能啟發思考，遂記錄下來。

一切的開始

起初是一段很簡單的代碼，開始僅僅是將外域的一些標識符轉換為域內的標識符。

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

邏輯上很簡單，實現的邏輯看上去也沒啥大問題，基本學校的老師也是這么教的。

語法規范

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

有函數式方法的盡量用

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

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

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

容易漏邏輯，盡量使用現成的方法

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

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

equals判定，常量寫前面

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

雖然前面判斷過null，所以這里并不會報空指針，但是但凡之后書寫前面漏了，這里就開始報錯了。

少用魔法值，定義常量

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

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

無狀態方法，可選擇定義為類靜態

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

方法本身跟所在類的實例對象狀態無關，且不會誘發線程安全問題，故符合被定義為static的條件，可先于對象創建在方法區，防止每個對象創建一次的時候，堆內存創建一次。

邏輯簡化

語法的問題強調完，就得再琢磨琢磨這段邏輯需不需要這么多代碼來表述了，乍眼一看沒問題，但其實沒必要寫這么多。

明確主體邏輯

判斷入參有效性 -> 處理核心邏輯 -> 缺省返回，其實這個方法的構建思路是非常標準且合乎常理的，思考習慣很好，只是在這個簡單的方法場景不免邏輯有些冗余。 其實再看這個方法，最核心的邏輯就是把字符串對應到數字上，其他不命中的情況返回null就可以了，那么簡化邏輯后，為空判定其實可以去掉，直接變為：

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;
}

語法簡化：三元運算符

再仔細看下場景有沒有成熟的范式，【布爾式+返回值+非此即彼】，三元運算符可堪一用。

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

語法簡化：Optional

這個場景范式也滿足，【可能為空，有后續處理，有條件，有缺省值】，Optional也算完美契合。

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

方法獨立存在的必要性討論

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

未來除了一種邏輯分支外，還會擴展其他分支，并且有被擴展的可能；

雖然還是一種邏輯分支，但是判斷的內容變長了，跟上下文和調用狀態有關；

雖然還是一種邏輯分支，但是邏輯總在調整；

一處定義，多點引用；

繼續拓展：定義枚舉

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

值枚舉構建

考慮繼續將入參的所有可能和出參的所有可能，可以構建為兩組枚舉值，這樣所有的同簇常量就被放到一起了。

public enum SaleTypeStrEnum{
  JX,
  // OTHERS
  ;
}


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

但是這個枚舉功能并不完善，因為從入參映射為SaleTypeStrEnum，依然需要一段轉換的邏輯，需要用到 SaleTypeStrEnum::name 來判定傳參命中了哪個，所以這個邏輯不應該放在枚舉外，繼續補充：

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;
  }
}

方法有了，但是每次傳進來值都要遍歷整個枚舉，O(n)效率太低了，還是老規矩，空間換時間。

public enum SaleTypeStrEnum{
  JX,
  // OTHERS
  ;
  
  /**
    * 預熱轉換關系到內存
    */
  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)了，那么最終方法體內也能使用switch管理原本的if-else

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

關系枚舉構建

再仔細思考下，其實這里在描述的內容，無論是哪個枚舉描述的內容都是同一件事物，方法本身就是描述兩個不同編碼的轉換關系，且轉換關系本身就是單向的，且映射路徑極度簡單，所以簡單化一點，可以直接構建轉換關系枚舉?。

@Getter
@AllArgsConstructor
public enum SaleTypeRelEnum {
  // 不在分別定義兩類變量，而是直接定義變量映射關系
  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);
  }
}

如果將轉關系作為枚舉，那么從職責上劃分，轉換這個動作應該是封閉在枚舉內的固有行為，而不該暴露在外，故原來對方法的引用其實應該轉為對關系枚舉中 SaleTypeEnum::parseCode 方法的引用，O(1)檢索且封閉性良好，同時支持更多簡單單向映射關系的管理，要是以后出現的新場景都是這種關系，那夠扛很久嘞。

繼續拓展：設計模式

枚舉的前提還是基于無狀態前提，如果轉換的的映射關系不再單純，變得復雜，枚舉的簡單映射管理就不work了。? “萬事不決，上設計模式”? 哎~就是玩兒~

策略模式-簡單實現

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

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


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


/**
  * 調用上下文
  */
@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;
    // 繼續擴展
    default:return null;
  }
  return context.parse();
}

當然，如果是這種沒有上下文強依賴的策略，無論是靜態單例還是Spring單例都會是一個不錯的選擇。SaleTypeParseContext本身可以繼續擴展內容和其他屬性繼續豐富參數，策略實現中也可以繼續針對更多參數擴充邏輯。

策略工廠-手動容器

策略是個好東西，但是簡單實現下，這里依然將策略實現的路由過程交給了調用方來做，那么每增加一種實現，調用點還要繼續改，要是恰好有若干調用點就完犢子了，并不優雅，所以搞個中間層容器工廠，解耦一下依賴。

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


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


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

容器內手動創建各個策略的實現的單例后進行托管，那調用方只需要去構建上下文就好了，實際調用的方法更換為 SaleTypeParseStrategyContainer::parse，那后續無論策略如何豐富，調用方都不需要再感知這部分變化。后續出現了新的策略實現，則在工廠內繼續追加路由表即可。

注冊與發現&策略工廠-Spring容器

如果考慮到策略會依賴Spring的bean和其他有狀態對象，那么這里也可以改成Spring的注入模式，同時繼續將“支持哪種情況”由托管方容器移動至策略內部，改成由策略實現自身去注冊到容器中。??

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);
  }
}

這樣的話，連容器都不用改了，追加策略實現的改動只與當前策略有關，調用方和容器類都不需要感知了，但是缺點就在于如果有倆策略支持的情況相同，取到的是哪個就聽天由命了~

注冊與發現&責任鏈

當然如果不能事先知道“支持哪種情況”，只能在運行時判斷“是否支持”，將事前判定改為運行時判定，廣義責任鏈會是一個不錯的選擇，把所有策略排成一排，誰舉手說自己能處理就誰處理。??

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);
  }
}

這樣的實現，依然可以將改動收束在策略本體上，修改相對集中，可以無耦地進行擴展。

其他拓展

以上還只是在JAVA語言內去玩一些花樣，在當前這種場景下肯定是有過度設計的嫌疑，7行代碼可以縮到1行，也可以擴充到70行，所以說嘛： “用代碼行數來考量一個程序員是不太合適滴！~”? 當然了，也還可以繼續借助其他的中間件搞花樣，包括但不限于：

植入Diamond走走動態配置開關的思路；

植入QLExpress搞搞邏輯表達式的思路；

把策略實現改成HsfProvider走分布式調用思路；

借助一些成熟的網關走服務路由的的調用思路；

就不再此再過多展開了。

總結

筆記向的內容帖子，用于活躍思維打開思路，沒啥高科技~

審核編輯：湯梓紅