【設計模式】漢堡中的設計模式——策略模式
每章一句
Yesterday home runs don't win today games
前言
哈嘍，大家好，今天要分享的知識點是關於策略模式的使用，觀看本文章可能需要耗費【8】分鍾,通過本文，你可以認識到以下幾個知識點
- 什么是策略模式
- 針對策略模式的局限，又有哪些解決辦法
- 枚舉策略了解一下？
情景帶入
話說昨天，麥當勞搞活動，板燒只要5塊大洋！！！下班了之后我就騎着心愛的小摩托飛奔過去，在等待了一段（long）時（long）間（time）...... 終於如願以償的握着這簡單的快樂
看着手里的板燒，心里突然就有了一些想法，現在搞活動，部分商品低價就可以拿到，但是搞活動不能一直搞吧，那不然肯定虧大本了，活動形式也總不能一成不變吧，需要保持新穎，多元化吸引顧客消費
那么變化點就出來了，這個形式是可以不斷變化的，例如會有這么幾種
- 打折活動的時候，只需要5塊大洋就能拿下一個漢堡
- 買一送一活動的時候，原價可以拿到兩個
- 優惠券活動，有的時候是有一些優惠券的，達到門檻減多少
- 沒有活動時，需要原價購買
我們常說要透過現象看本質，盡管形式很多，但是萬變不離其中，最終是要付錢產生價值的，那就來分析一下這個流程吧！
開始分析
我們再來模擬一下，顧客在各種形式下是怎么點餐的
- 沒有活動時，我把漢堡添加到購物車，創建訂單，支付，等待出餐
- 搞打折活動時，漢堡只需要5塊大洋，通過指定鏈接，把漢堡加到購物車，創建訂單，支付，等待出餐
- 搞買一送一活動時，把漢堡添加到購物車，創建訂單，支付，等待出餐
- 搞滿減活動時，把漢堡和中薯、那么大雞排添加到購物車，湊足滿減金額，創建訂單，使用優惠券，支付出餐
通過畫圖的形式展示一下上述的邏輯
上面是完整的步驟，簡化一下，我們只關注產生價值的部分，也即客戶支付了多少錢，取到了哪些食物
進一步說就是，商戶可以隨意切換形式，比如昨天有5元的板燒，今天點進去看發現沒有了，但是多出來了其他的優惠，例如【麥樂雞20粒】優惠券，后天進去發現優惠券都沒了，只能原價購買等情況；但是無論形式是這樣的，最終產出時的步驟都是一致的，例如這里就是支付和取餐
繞了這么久，其實就是要引出今天的主角————策略模式
策略模式
標准定義以及類圖
定義一組算法，並封裝每個算法，讓它們彼此可以交換使用。策略模式讓這些算法在客戶端中使用起來更加獨立
如果以上述例子來看，所有形式都是一種特定的算法
- 原價購買是一種算法
- 打折也是一種算法
- 優惠券滿減也是算法
- 買一送一也是算法
- ....
算法具體的如何實現的，客戶端不管，客戶端只知道，我可以任意切換形式，並且達成想要的效果
就好比顧客知道有這個活動，但不用知道這個活動的其他細節，我只需要按照步驟操作即可有優惠
嘗試編碼
既然上述幾種情況最終都需要支付和取餐，那么我們直接就定義一個頂層接口管理這些算法（相當於是AbstractStrategy），接口中有兩個方法
- 一個是返回實際需要付多少錢
- 一個是返回實際取到的食物列表
具體如何實現，就是每個算法內部的事情了，別人管不了，相當於是每一個ConcentrateStrategy
從類圖上看到，標准的策略模式還要有一個組件Context，他就類似是策略模式的客戶端，要調用哪一個策略，跟Context溝通，不跟具體實現溝通，這樣做的好處就是實現客戶端（真正的調用方）與具體實現間的解耦，如下圖所示
所以，根據設計，我們把代碼給敲一下
-
首先是頂層接口代碼
-
然后是各個具體算法的實現
-
Context代碼
-
客戶端調用情況
輸出結果
如果我要新添加一種形式呢？
麥當勞“壕無人性”地說，今天薯條免費贈送，那么針對這種情況，很明顯現有的算法家族是不支持的，那么我們只需要再添加一種算法，叫做【FreePrice】，然后交給Client調用即可
我們完全不需要動其他已經寫好的算法，這很符合OCP原則，並且算法的具體實現也被完美的隱藏在各個實現類中，實在是很nice
策略模式的優點
其實剛剛也講了，這里再總結一下
- 算法的具體實現封裝在各個實現類中，客戶端不需要知道
- 客戶端可以根據場合隨意切換到底要使用哪一種策略
- 將客戶端與具體實現通過Context解耦，即符合OCP原則，又可以讓具體算法獨立發展而不會影響其他類修改
策略模式的局限
那么，可能有小伙伴就像提問了，策略模式這么牛逼，他就沒有一點局限性嗎？這里引用我在看《Head First 設計模式》中看到的一段話，他的意思是
設計模式的定義告訴我們，問題包含了一個目標和一組約束；光明的方向就是你的目標，黑暗的方向就是這些約束
光明與黑暗總是相伴而生，所以策略模式的約束是什么？不妨從我們實際調用的方向入手，思考一下🤔
商戶在實際設置新行為的時候，肯定是會有一個UI界面，會有下拉選擇本次要推出的形式，針對不同的形式，所需要的參數也不盡相同，例如形式是優惠卷滿減的時候，需要有滿減閾值，滿減多少，優惠券時效等等參數
那么發送到后端創建的時候，url請求也許是這樣子的（簡單給個例子）：newActivity?type=1
其中type就是標識，我們具體選擇的策略，比如
- type=1代表是原價
- type=2代表是打折
- type=3代表是滿減
然后回看一下剛剛寫的代碼，在Client端調用，簡直就是太過於理想化了，真正調用的時候，不可能這么寫的
實際上，對應處理的Controller（客戶端）在接收到方法的時候，最基礎時要這么來判斷
//偽代碼,暫不校驗字段有效性問題
if (1 == type)
then xxxx
else if (2 == type)
then xxxx
else if (3 == type)
then xxxx
else if (4 == type)
then xxxx
....
你說這個，跟我了解策略模式的局限性到底有什么關系啊？其實仔細品一下，就會發現，盡管我們把各個算法的實現細節都給隱藏了，當時我們依然需要知道有多少種策略，換言之就是，我們在選擇策略的時候不免要進行判斷，這就是策略模式一個局限
第二個就是，每次都需要新建一個類單獨做一個算法策略，如果有很多很多的算法策略，就會導致類結構非常的膨脹，此時，就不易於維護和管理
解決局限性問題
針對客戶端存在一大堆的if-else，我們使用簡單工廠的形式配合把他們都封裝起來
簡單工廠+策略模式解決客戶端大量if-else情況
原來的設計不變，把Context給替換成HandlerFactory，通過靜態方法返回信息，這里為了更加貼合實際，定義了兩個VO對象
簡單工廠
最終客戶端調用
使用postman進行測試，為了方便起見，參數就不改變了，就改變type，實際上是不同的type，參數也會不相同
-
type為1，原價方式
-
type為2，優惠券滿減策略
-
type為3，折扣策略
-
type為4，買一送一策略
-
type為5，免費送策略
通過簡單工廠+策略模式，我們把原本存在於客戶端中的判斷給挪到工廠里面，把所有的運行邏輯都隱藏起來了；每次有新的策略，只需要新建一個類，修改一下HandlerFactory中的selectStrategy方法即可
不過這也導致了HandlerFactory這個類違背了OCP原則，但是相對於一大段的if-else直接暴露再客戶端，這種方法無疑是值得考慮的
枚舉策略方式
或許在看完【簡單工廠+策略模式】之后小伙伴會有所疑問，這不就是把客戶端的判斷邏輯給轉移到工廠中而已，雖然對於客戶端來說，會更加的清爽，可是似乎沒有根本性的解決問題，工廠中把if-else換成了switch-case，新的策略該創建類還是要創建類，所以該膨脹還是得膨脹啊。。。
那沒辦法了，只能出絕招了，
使用枚舉策略模式，相當於策略來說，枚舉策略更像是他的改良升級版本，使用起來也更加的靈活，不需要創建大量的類來充當各個具體實現，也不需要滿屏幕的if-else或者switch-case，看起來就相當的誘人
枚舉大家都使用過，常用來定義一些常量信息，而枚舉策略就是在枚舉類里邊加上抽象方法，讓每個常量都實現這些方法
例如，我在枚舉里邊定義這兩個方法
那么我的每一個枚舉成員都必須實現這兩個方法
給出完整的代碼
客戶端調用情況
可以發現，原本各個實現類都不需要了，只需要在枚舉中定義成員，即可達成原來的效果，而且在匹配對應的策略時，直接使用循環的方式，看起來非常的清爽
如果要添加新的策略，直接在枚舉里邊添加成員，實現對應的方法即可，而且將所有的策略統一管理起來，方便維護
唯一的缺點，可能就是策略越來越多的時候，這個枚舉類也會越來越長，但是通過成員來管理，注釋寫好，也不會顯示很混亂
總結
所以，策略模式到底是什么？
就是提供很多很多的算法，讓客戶端可以動態的選擇使用哪一個，其實在MVC中，View通過url把請求給到Controller處理，就是一種典型的策略選擇，View可以隨時更換url，綁定給另外一個Controller處理
事務都有兩面性，所以針對策略模式的局限，我們需要做額外的工作，把不好的影響降到我們能接受的度
好啦，本期文章就到這里了，限於本人水平的問題，如果有說得不對的地方，歡迎指出！我們下期再見！