記一次策略模式的使用

每次說起設計模式腦子裡總是想起大學裡學的23中設計模式。23中設計模式，能記住的屈指可數，在工作中用到的更是少之又少。當然，設計模式聽著總是感覺很高大上，自己那點業務需求有點簡單的if-else，三下五除二就打完收工了，如果絞盡腦汁弄了設計模式，**量倍增，看不到到底好在**，反而增加了工作量。這次就用乙個需求說一下，策略模式的使用。

首先，還是老生常談，了解一下策略模式的定義。

在策略模式（strategy pattern）中，乙個類的行為或其演算法可以在執行時更改。

乙個類的行為或其演算法可以在執行時更改，說白了就是if-else。那麼為什麼不用if-else吶？

假如有這麼乙個需求：

一批客戶訂單，一批商家。每個商家有個分值，可以理解為權重。需要將這些待處理的訂單按設定的分派規則分派給這些商家

分派規則a: 按照商家分值從高到低依次迴圈分派，直到分派完畢

分派規則b: 按照商家分值在總分值中的比例，從訂單中按照比例分派

大致實現流程

//1.獲取待分派訂單
//2.獲取商家
//3.根據分派規則分派
if(規則a)
else
if(規則b)
//4.結束

半個小時你就寫完了需求。半個月後產品又加了兩個分派規則：

分派規則c: 按照不同分值分組，按照不同分值比例分派訂單，同組內輪詢分派

分派規則d: 按照不同分值分組，按照不同分值比例分派訂單，同組內按照商家客戶評級排序依次分派

於是接著加if-else

//3.根據分派規則分派
if(規則a)
else
if(規則b)
else
if(規則c)
else
if(規則d)

這個時候有沒有這塊**有點難受呀，這時候產品接著加分派規則，然後有的分派規則交給其他同事開發，大家接著填if-else，**開始衝突，各種分派邏輯中又巢狀各種if-else。最後這塊分派訂單的邏輯就變成了誰也不想維護的又臭又長的if-else的巢狀**毒瘤。後面可能更改乙個if，牽一髮而全崩盤。

這個情況其實可以考慮使用策略模式。我們用策略模式簡單改造一下。

//分派介面 inte***ce basedispatchservice

規則a分派實現類

@service
("adispatch"
)class
adispatchservice
implements
basedispatchservice
; }

規則b分派實現類

@service
("bdispatch"
)class
bdispatchservice
implements
basedispatchservice
; }

執行分派流程：

class
dispatch")
private string dispatchcode;
@autowired
private map
dispatchservicemap;
void
dispatch()
}

總結：

優點：

1、演算法可以自由切換。

2、避免使用多重條件判斷。

3、擴充套件性良好。

缺點：

1、策略類會增多。

2、所有策略類都需要對外暴露。

使用場景：

1、如果在乙個系統裡面有許多類，它們之間的區別僅在於它們的行為，那麼使用策略模式可以動態地讓乙個物件在許多行為中選擇一種行為。

2、乙個系統需要動態地在幾種演算法中選擇一種。

注意事項：如果乙個系統的策略多於四個，就需要考慮使用混合模式，解決策略類膨脹的問題。

工作中也用了幾次策略模式，效果還可以。

其實到現在，用的最多的也不外乎策略模式、單例模式、工廠模式等，因為大部分的業務場景其實就是if-else的組合。

23中設計模式用的就那麼少嗎？一點也不是，設計模式說白了就是前人總結的優秀的開發經驗，經驗就是踩過坑總結出來的教訓。

我們使用的各種優秀的開源框架裡，處處有著設計模式的身影。只是我們在享受優秀框架帶給我們便利的同時，忘了框架底層中設計模式的優點罷了。

準備看看設計模式在優秀開源框架中的應用，它山之石可以攻玉。nice!

記一次策略模式的使用

記一次的使用

記一次muse ui 使用

記一次vue splitpane使用

記一次策略模式的使用

記一次的使用

記一次muse ui 使用

記一次vue splitpane使用

相關推薦