一、委派模式
委派模式（Delegate Pattern）：指負責任務的調度和分配任務，跟代理模式很像，可以看做是一種特殊情況下的靜態代理的全權代理，但是代理模式注重過程，而委派模式注重結果。（屬於行為型模式，但它不屬於GOF的23種設計模式之一。類名以Delegate和Dispatcher結尾的一般都是委派模式）
委派模式在Spring中應用非常多，大家常用的DispatcherServlet其實就用到了委派模式。現實生活中也常有委派的場景發生，例如：老板（Boss）給項目經理（Leader）下達任務，項目經理會根據實際情況給每個員工派發工作任務，待員工把工作任務完成之后，再由項目經理匯報工作進度和結果給老板，業務場景如下圖：
例子1：用代碼來模擬一下這個業務場景，定義一個IEmployee員工接口：
定義一個員工EmployeeA類：
定義一個員工EmployeeB類：
定義一個項目經理Leader類：
定義一個Boss類下達命令：
測試代碼：
運行結果：
類結構圖：
通過上面的代碼，生動地還原了項目經理分配工作的業務場景，也是委派模式的生動體現。
委派模式在源碼中的體現
例子2：還原SpirngMVC的DispatcherServlet是如何實現委派模式的。定義一個MemberController類 ：
定義一個OrderController類：
定義一個DispatcherServlet類：
配置web.xml文件：
二、策略模式
1、策略模式（Strategy pattern）：指定義了算法家族、分別封裝起來，讓它們之間可以相互替換，此模式讓算法的變化不會影響到使用算法的用戶。（屬於行為型模式）
2、適用場景
- 假如系統中有很多類，而他們的區別僅僅在於他們的行為不同
- 一個系統需要動態地在幾種算法中選擇一種
3、優點
- 策略模式符合開閉原則
- 避免使用多重條件轉移語句，如if...else...和switch語句
- 使用策略模式可以提高算法的保密性和安全性
4、缺點
- 客戶端必須知道所有的策略，並且自行決定使用哪一個策略類
- 代碼中產生非常多策略類，增加維護難度
例子1：有一個課程優惠活動，優惠策略會有多種，如領優惠券抵扣、返現促銷等。下面用代碼來模擬：
定義一個促銷策略PromotionStragegy接口：
定義一個優惠券折扣策略CouponStragegy類：
定義一個返現促銷策略CashbackStrategy類：
定義一個無優惠EmptyStrategy類：
定義一個促銷活動方案PromotionActivity類：
編寫客戶端測試類：
此時大家會發現，如果把上面這段測試代碼放到實際的業務場景其實並不實用。因為我們做活動時往往是根據不同的需求對促銷策略進行動態選擇的，並不會一次性執行多種優惠。所以，我們的代碼通常會這樣寫：
這樣改造之后，滿足了業務需求，客戶可根據自己的需求選擇不同的優惠策略了。但是，經過一段時間的業務積累，我們的促銷活動會越來越多。於是，我們的程序猿小哥哥就忙不贏了，每次上活動之前都要通宵改代碼，而且要做重復測試，判斷邏輯可能也變得越來越復雜。這時候，我們可以結合之前學過的單例模式和工廠模式。定義一個策略工廠PromotionStrategyFactory類：
這時候客戶端代碼就應該這樣寫了：
類結構圖：
代碼優化之后，程序猿小哥哥維護工作就輕松多了，每次上新活動，不影響原來的代碼邏輯。
例子2：一個常見的應用場景就是大家在下單支付時會提示選擇支付方式，如果用戶未選，系統也會使用默認推薦的支付方式進行結算。
定義一個支付渠道Payment抽象類，聲明支付規范和支付邏輯：
定義具體的支付方式，支付寶AliPay類：
微信支付WechatPay類：
定義一個支付狀態的包裝類PayState：
定義一個支付策略管理PayStrategy類：
定義一個Order訂單類：
測試代碼：
運行結果：
三、委派模式與策略模式綜合應用
回顧一下DispatcherServlet的委派邏輯，代碼如下：
這樣的代碼擴展性不太優雅，也不現實，因為我們實際項目中一定不止這幾個Controller，往往是成千上萬個Controller，顯然我們不能寫成千上萬個if...else...。那么我們可以結合策略模式改造優化一下：
定義一個Handler類：
改造DispatcherServlet類：
上面的代碼結合了策略、工廠、單例模式。