4.5 工廠模式重構代碼

接下來使用工廠模式優化代碼，也算是一次代碼重構。當整理代碼流程并重構后，會發現代碼結構更清晰了，也具備了應對下次新增業務需求的擴展性。

注意：以下這段代碼重構只是抽離出最核心的部分，方便理解和學習。在實際的業務開發中，還需要額外添加一些其他邏輯，在使用上進行完善，例如調用方式、參數校驗和Spring注入等。

4.5.1 工程結構

從上面的工程結構來看，是否有一種感覺：這樣的工程看上去更清晰，類的職責更明確，分層可以更好地擴展，可以通過類名就能大概知道每個類的功能。如果暫時還無法理解為什么要這樣修改也沒有關系，通過源碼進行實戰操作幾次，就可以慢慢掌握工廠模式的技巧了。

為了便于理解整個工程中相關類的具體作用，可以參考圖4-3。

4.5.2 定義發獎接口

·對于所有的獎品，無論是實物商品、優惠券還是第三方兌換卡（愛奇藝），都需要通過程序實現此接口并處理。這樣的方式可以保證入參和出參的統一性。

·接口的入參包括：用戶 ID（uId）、獎品 ID（commodityId）、業務 ID（bizId）及擴展字段（extMap），用于處理發放實物商品時的收貨地址。

4.5.3 實現三種發獎接口

1.優惠券

2.實物商品

3.第三方兌換卡（愛奇藝）

·從上面代碼實現中可以看到，每一種獎品的實現都包裝到自己的類中，當新增、修改或刪除邏輯時，都不會影響其他獎品功能的測試，可以降低回歸測試和相應的連帶風險。

·如果有新增的獎品，只需要按照此結構進行填充對應的實現類即可。這樣的實現方式非常易于維護和擴展。

·在統一了入參及出參后，調用方不再需要關心獎品發放的內部邏輯，按照統一的方式即可處理。

4.5.4 創建商店工廠

這是一個商店的工廠實現類，里面提供了兩種獲取工廠實現類的方法：一種是依賴獎品類型，另一種是根據獎品類信息進行實例化。這兩種方式都有自己的使用場景，按需選擇即可。在第一種實現方式中用到了 if判斷，這里既可以選擇使用 switch語句，也可以使用map結構進行配置（key是類型值，value是具體的邏輯實現）。通過商店工廠類獲取各種獎品服務，可以非常干凈、整潔地處理業務邏輯代碼。后續新增的獎品按照這樣的結構擴展即可。另外，需要注意關于編碼規范和相關工具的檢查，比如p3c插件，這些插件會檢查if語句是否有括號包裝。本書為了讓代碼更加簡短，也更好地展示核心邏輯，做了簡化處理。在實際的業務開發中，可以補全if語句后的大括號以及會選擇用equal比對。

4.5.5 測試驗證

編寫單元測試。

在以上的單元測試類中，商店工廠類中的兩個方法都寫好了各自的測試代碼。接下來驗證并查看運行結果。

testStoreFactory01（），測試結果。

testStoreFactory02（），測試結果。

從運行結果可以看到，這兩種獲取工廠實現的接口都可以滿足業務需求。在實際使用中按需選擇即可。這段重構后的代碼既滿足了業務方和產品經理的需求，也滿足了研發人員對代碼質量的追求。另外，從運行的測試結果也可以看出來，在進行封裝后，這樣一整套發放獎品服務有統一的入參、統一的結果。既提高了代碼的結構性，也讓工程易于維護和擴展。