本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/8057654.html,記錄一下學習程序以備后續查用,
一、引言
今天我們要講行為型設計模式的第七個模式--策略模式,在現實生活中,策略模式的例子也非常常見,例如:在一個公司中,會有各種作業人員:有普
通員工、有軟體架構師、有部門經理,當然也有公司的CEO等等,這些作業人員負責的作業不同、擔負的職責也不同,報酬也各不相同,
每種作業人員都有自己的工資,但是不同工種其工資的計算方式是不一樣的,如果不采用策略模式來實作這個需求的話,我們可能會這樣來做:定義
一個工資類,該類有一個屬性來標識作業人員的型別,并且有一個計算工資的CalculateSalary()方法,在該方法體內對作業人員型別進行判斷,然后通過
if-else陳述句來計算不同型別的工資,這樣做確實可以解決這個場景,但是不利于擴展,如果系統后期需要增加一種新的工種時,需對CalculateSalary方法
進行修改(再添加一個判斷陳述句),這樣明顯違背了“開閉原則”,
此時,我們可以考慮使用策略模式來解決這個問題,既然工資計算方法是這個場景中的變化部分,此時自然想到的是對工資演算法進行抽象,不同工種
的工資可以用不用的策略演算法具體實作,若想得到某個作業人員的工資,使用其對應的工資演算法策略進行計算就可以了,
二、策略模式介紹
策略模式:英文名稱--Strategy Pattern;分類--行為型,
2.1、動機(Motivate)
在軟體構建程序中,某些物件使用的演算法可能多種多樣,經常改變,如果將這些演算法都編碼到物件中,將會使物件變得例外復雜,而且有時候支持不使
用的演算法也是一個性能負擔,如何在運行時根據需要透明地更改物件的演算法,將演算法與物件本身解耦,從而避免上述問題?
2.2、意圖(Intent)
定義一系列演算法,把它們一個個封裝起來,并且使它們可互相替換,該模式使得演算法可獨立于使用它的客戶而變化,——《設計模式》GoF
2.3、結構圖(Structure)

2.4、模式的組成
可以看出,在策略模式的結構圖有以下角色:
1)環境角色(Context):持有一個Strategy類的參考,
需要使用ConcreteStrategy提供的演算法,
內部維護一個Strategy的實體,
負責動態設定運行時Strategy具體的實作演算法,
負責跟Strategy之間的互動和資料傳遞,
2)抽象策略角色(Strategy):定義了一個公共介面,各種不同的演算法以不同的方式實作這個介面,Context使用這個介面呼叫不同的演算法,一般使用
介面或抽象類實作,
3)具體策略角色(ConcreteStrategy):實作了Strategy定義的介面,提供具體的演算法實作,
2.5、策略模式的具體實作
在現實生活中,策略模式的例子也是很多的,例如:一個公司會有很多工種,每個工種負責的作業不同,其對應的工資計算方法也會不同,我們今天就
以工資的計算為例來說明策略模式的使用,實作代碼如下:
class Program { /// <summary> /// 環境角色--相當于Context型別 /// </summary> public sealed class SalaryContext { public ISalaryStrategy SalaryStrategy { get; set; } public SalaryContext(ISalaryStrategy strategy) { SalaryStrategy = strategy; } public void GetSalary(double income) { SalaryStrategy.CalculateSalary(income); } } /// <summary> /// 抽象策略角色--相當于Strategy型別 /// </summary> public interface ISalaryStrategy { //工資計算 void CalculateSalary(double income); } /// <summary> /// 程式員的工資--相當于具體策略角色ConcreteStrategyA /// </summary> public sealed class ProgrammerSalary : ISalaryStrategy { public void CalculateSalary(double income) { Console.WriteLine("程式員的工資是:基本工資(" + income + ")底薪(" + 8000 + ")+加班費+專案獎金(10%)"); } } /// <summary> /// 普通員工的工資--相當于具體策略角色ConcreteStrategyB /// </summary> public sealed class NormalPeopleSalary : ISalaryStrategy { public void CalculateSalary(double income) { Console.WriteLine("普通員工的工資是:基本工資(" + income + ")底薪(3000)+加班費"); } } /// <summary> /// CEO的工資--相當于具體策略角色ConcreteStrategyC /// </summary> public sealed class CEOSalary : ISalaryStrategy { public void CalculateSalary(double income) { Console.WriteLine("CEO的工資是:基本工資(" + income + ")底薪(20000)+專案獎金(20%)+公司股票"); } } static void Main(string[] args) { #region 策略模式 //普通員工的工資 SalaryContext context = new SalaryContext(new NormalPeopleSalary()); context.GetSalary(3000); //CEO的工資 context.SalaryStrategy = new CEOSalary(); context.GetSalary(6000); Console.Read(); #endregion } }View Code
運行結果如下:

三、策略模式的實作要點
Strategy及其子類為組件提供了一系列可重用的演算法,從而可以使得型別在運行時方便地根據需要在各個演算法之間進行切換,所謂封裝演算法,支持演算法的
變化,Strategy模式提供了用條件判斷陳述句以外的另一種選擇,消除條件判斷陳述句,就是在解耦合,含有許多條件判斷陳述句的代碼通常都需要Strategy模式,
與State類似,如果Strategy物件沒有實體變數,那么各個背景關系可以共享一個Strategy物件,從而節省物件開銷,Strategy模式適用的是演算法結構中整個
演算法的改變,而不是演算法中某個部分的改變,
Template Method模式:執行演算法的步驟協議是本身放在抽象類里面的,允許一個通用的演算法操作多個可能實作,
Strategy模式:執行演算法的協議是在具體類,每個具體實作有不同通用演算法來做,
3.1、策略模式的主要優點
1)策略類之間可以自由切換,由于策略類都實作同一個介面,所以使它們之間可以自由切換,
2)易于擴展,增加一個新的策略只需要添加一個具體的策略類即可,基本不需要改變原有的代碼,
3)避免使用多重條件選擇陳述句,充分體現面向物件設計思想,
3.2、策略模式的主要缺點
1)客戶端必須知道所有的策略類,并自行決定使用哪一個策略類,這點可以考慮使用IOC容器和依賴注入的方式來解決,關于IOC容器和依賴注入
(Dependency Inject)的文章可以參考:《IoC 容器和Dependency Injection 模式》
2)策略模式會造成很多的策略類,
3.3、在下面的情況下可以考慮使用策略模式
1)一個系統需要動態地在幾種演算法中選擇一種的情況下,那么這些演算法可以包裝到一個個具體的演算法類里面,并為這些演算法類提供一個統一的介面,
2)如果一個物件有很多的行為,如果不使用合適的模式,這些行為就只好使用多重的if-else陳述句來實作,此時,可以使用策略模式,把這些行為轉移到
相應的具體策略類里面,就可以避免使用難以維護的多重條件選擇陳述句,并體現面向物件涉及的概念,
四、.NET中策略模式的實作
在.NET中也不乏策略模式的應用例子,例如,在.NET中,為集合型別ArrayList和List<T>提供的排序功能,其中的實作就利用了策略模式,定義了
IComparer介面來對比較演算法進行封裝,實作IComparer介面的類可以是順序或者逆序地比較兩個物件的大小,具體.NET中的實作可以使用反編譯工具查看
List<T>.Sort(IComparer<T>)的實作,其中List<T>就是承擔著環境角色,而IComparer<T>介面承擔著抽象策略角色,具體的策略角色就是實作了
IComparer<T>介面的類,List<T>類本身實作了存在實作了該介面的類,我們可以自定義繼承與該介面的具體策略類,
五、總結
策略模式不是很難,可以說很簡單,或許大家已經在實際編碼中使用過該模式了,還是老話,我們要想清楚地使用每一個模式,要理解它們的優缺點以及
它們的使用場合,使用模式切記不能一上來就使用模式,我們應該通過迭代的方式來寫代碼,在編碼的時候,第一印象很重要,第一次怎么想的就怎么寫,
如果有需求的改變且改變比較頻繁,然后我們再來仔細分析變化點,并尋找合適的模式來解決相應的問題,
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/71353.html
標籤:C#
上一篇:C# 訪問修飾符
