35.2 混編小結 回顧一下我們在該案例中使用了幾個模式。 ● 策略模式 負責對扣款策略進行封裝，保證兩個策略可以自由切換，而且日后增加扣款策略也非常簡單容易。 ● 工廠方法模式 修正策略模式必須對外暴露具體策略的問題，由工廠方法模式直接產生一個具體策略對象，而其他模塊則不需要依賴具體的策略。 ● 門面模式 負責對復雜的扣款系統進行封裝，封裝的結果就是避免高層模塊深入子系統內部，同時提供系統的高內聚、低耦合的特性。 我們主要使用了這三個模式，它們的好處是靈活、穩定，我們可以設想一下可能有哪些業務變化。 ● 扣款策略變更 增加一個新扣款策略，三步就可以完成：實現IDeduction接口，增加StrategyMan配置項，擴展扣款策略的利用（也就是門面模式的getDeductionType方法，在實際項目中這里只需要增加數據庫的配置項）。減少一個策略很簡單，修改扣款策略的利用即可。變更一個扣款策略也很簡單，擴展一個實現類口就可以了。 ● 變更扣款策略的利用規則 我們的系統不想大修改，還記得我們提出的狀態模式嗎？這個就是為策略的利用服務的，變更它就能滿足要求。想把IC卡也納入策略利用的規則也不復雜。其實這個變更還真發生了，系統投產后，業務提出考慮退休人員的情況，退休人員的IC卡與普通在職員工一樣，但是它的扣款不僅僅是根據交易編碼，還要根據IC卡對象，系統的變更做法是增加一個扣款策略，同時擴展扣款利用策略，也就是數據庫的配置項，在getDeductionType中新擴展了一個功能：根據IC卡號，確認是否是退休人員，是退休人員，則使用新的扣款策略，這是一個非常簡單的擴展。 這就是一個mini版的金融交易系統，沒啥復雜的，剩下的問題就是開始考慮系統的魯棒性，這才是難點。