4.4 違背設計模式實現

如果不考慮程序的任何擴展性，只為了盡快滿足需求，那么對這三種獎勵的發放只需使用if…else語句判斷，調用不同的接口即可。我們先按照這樣的方式實現業務需求，最后再使用設計模式重構這段代碼，方便對照理解。

4.4.1 工程結構

整個工程結構非常簡單，包括一個入參對象AwardReq、一個出參對象AwardRes，以及獎品發放的服務類PrizeController。接下來，給出核心抽獎類的實現代碼。

4.4.2 if…else實現需求

上述代碼使用了if…else語句，用非常直接的方式實現了業務需求。如果僅從產品需求角度來說，確實實現了相應的功能邏輯。甚至靠這樣簡單粗暴的開發方式，也許能讓需求提前上線。既然這樣的代碼可以實現快速交付，又存在什么問題呢？在互聯網業務快速迭代的情況下，這段代碼會在源源不斷的需求中迭代和拓展。如果這些邏輯都用 if…else填充到一個類里，則非常難以維護。這樣的代碼使用的時間越久，其重構成本就越高。重構前需要清理所有的使用方，測試回歸驗證時間加長，帶來的風險也會非常高。所以，很多研發人員并不愿意接手這樣的代碼，如果接手后需求開發又非常緊急，可能根本來不及重構，導致這樣的if…else語句還會繼續增加。

4.4.3 測試驗證

下面通過一個單元測試驗證上面編寫的接口。養成單元測試的好習慣，可以增強代碼的質量。

測試模擬發放優惠券。

測試模擬發放實物商品。

測試模擬發放第三方兌換卡（愛奇藝）。

雖然運行結果正常，滿足當前所有的業務產品需求，但這樣的實現方式不易于擴展，也非常難以維護，風險很高。