最近在日常工作過程中接到乙個任務：需要提供乙個介面，根據不同的意圖返回給客服端不同的答案，每個意圖去識別答案的演算法都有各自不同的邏輯。作為乙個合格的crud程式設計師，接到這個需求腦袋裡的第一反應就是用if-else去實現，但是這樣寫**太醜陋了，每個else裡面都會有大量的業務邏輯，對於後期接坑的人肯定會很頭痛，這個時候突然想到同事阿偉給我說過的策略模式，之後讓**看起來更優雅，擴充套件維護起來也更簡單明確。
概述 該模式定義了一系列演算法，並將每個演算法封裝起來，使它們可以相互替換，且演算法的變化不會影響使用演算法的客戶。策略模式屬於物件行為模式，它通過對演算法進行封裝，把使用演算法的責任和演算法的實現分割開來，並委派給不同的物件對這些演算法進行管理。
模式中的角色
策略類（stratege）：定義所有支援的演算法的公共介面或者抽象類。
具體策略類（concrete stratege）：封裝了具體的演算法或行為，繼承於stratege類。
上下文類（context）：用乙個concretestratege來配置，維護乙個對stratege物件的引用。
public
class
strategytest
}//策略類
inte***ce
strategy
//具體實現類意圖a，返回結果a
class
strategya
implements
strategy
}//具體實現類意圖b，返回結果b
class
strategyb
implements
strategy
}//環境類
class
context
public
void
setstrategy
(strategy strategy)
public
void
stragymethod()
}
使用場景
實現某個功能需要不同的演算法要求事
優點2.1、策略模式是一種定義一系列演算法的方法，從概念上來看，所有演算法完成的都是相同的工作，只是實現不同，它可以以相同的方式呼叫所有的演算法，減少了各種演算法類與使用演算法類之間的耦合，起到解耦效果。
2.2、策略模式把不同的演算法維護在自己各種的類中，便於維護和擴充套件，也消除了**中大量的if-else。
缺點會有很多的策略類。
策略模式在工作中應用
物流系統要新增包裹資料，現在物流的上游有三種包裹 線上的包裹，線下的包裹，外部的包裹，每種包裹在新增時會有些不同的操作，比如線上線下的包裹新增後要發訊息給訂單履約中心方便監控，線上包裹新增時要判斷包裹是否需要抽檢，釘箱，並生成相關的資料等。每種包裹都有其特殊的操作，從系統維護的角度上說，可以使用策略...
責任鏈模式在工作中應用
判斷配件是否需要抽檢，現在系統有三種抽檢規則 商品規則，組織規則，其它規則，配件滿足任一規則即需要抽檢 因為配件要依次經過三種規則，所以考慮使用責任鏈模式 讓配件依次匹配商品規則，組織規則，其它規則，滿足任一規則即返回，不滿足繼續用下一規則判斷。結構 1.策略模版，建立乙個抽象類 commonins...
設計模式在工作中的應用（二）
這裡我們不介紹如何進行解析生成sql語句，怎麼解析的不重要，只要知道這些都是解析類，轉換為sql語句的不同部分。我是想說說針對上面的需求，我是如何考慮的。需要能夠使用sqlserver的函式？大概想一想，感覺很容易啊，不就是封裝乙個函式類，實現sqlserver資料庫的函式。是的，最根本的實現也就是...