架構師教你kill祖傳石山代碼重複/大量ifelse（上）

本文就教你如何優雅消除重複代碼并改變你對業務代碼沒技術含量的觀念。

1 crud 工程師之“痛”

很多 crud 工程師抱怨業務開發沒有技術含量，什麼設計模式、高并發都用不到，就是堆CRUD。每次面試被問到“講講常用設計模式？”，都隻能把單例講到精通，其他設計模式即使聽過也隻會簡單說說，因為根本沒實際用過。

對于反射、注解，也隻是知道在架構中用的很多，但自己又不寫架構，更不知道該如何使用。

設計模式是世界級軟體大師在大型項目的經驗所得，是被證明利于維護大型項目的。

反射、注解、泛型等進階特性在架構被大量使用，是因為架構往往需要以同一套算法應對不同資料結構，而這些特性可以幫助減少重複代碼，也是利于維護。

提升項目的可維護性是每個 coder 必須注意的，非常重要的一個手段就是減少代碼重複，因為重複過多會導緻：

容易修改一處忘記修改另一處，造成Bug

有一些代碼并非完全重複，而是相似度高，修改這些類似的代碼容易改（cv）錯，把原本有差別的地方改成一樣

2 工廠+模闆方法模式，消除多if和重複代碼

2.1 需求

開發購物車下單，對不同使用者不同處理：

• 普通使用者需要收取運費，運費是商品價格的10%，無商品折扣
• VIP使用者同樣需要收取商品價格10%的快遞費，但購買兩件以上相同商品時，第三件開始享受一定折扣

• 内部使用者可以免運費，無商品折扣

實作三種類型的購物車業務邏輯，把入參Map對象（K：商品ID，V：商品數量），轉換為出參購物車類型Cart。

2.2 菜鳥實作

• 購物車

• 

• 購物車中的商品

• 

2.2.1 普通使用者

2.2.2 VIP使用者

VIP使用者能享受同類商品多買的折扣。隻需額外處理多買折扣部分。

2.2.3 内部使用者

免運費、無折扣，隻處理商品折扣和運費時的邏輯差異。

三種購物車超過一半代碼重複。

雖然不同類型使用者計算運費和優惠的方式不同，但整個購物車的初始化、統計總價、總運費、總優惠和支付價格邏輯都一樣。

代碼重複本身不可怕，可怕的是漏改或改錯。

比如，寫VIP使用者購物車的同學發現商品總價計算有Bug，不應該是把所有Item的price加在一起，而是應該把所有Item的price*quantity相加。

他可能隻修VIP使用者購物車的代碼，漏了普通使用者、内部使用者的購物車中重複邏輯實作的相同Bug。

有三個購物車，就需根據不同使用者類型使用不同購物車。

• 使用多if實作不同類型使用者調用不同購物車process

• 

• 就隻能不斷增加更多的購物車類，寫重複的購物車邏輯、寫更多if邏輯嗎？

當然不是，相同的代碼應該隻在一處出現！