定義
首先介紹一下眾多博客文章中提到的策略模式的概念,針對于文章結構構成,請允許小編在此處再細說一下,
策略模式:百度百科中引述為:指物件有某個行為,但是在不同的場景中,該行為有不同的實作演算法,
1.策略模式是對演算法的包裝,是把使用演算法的責任和演算法本身分割開來,委派給不同的物件管理,
2.策略模式通常把一個系列的演算法包裝到一系列的策略類里面,作為一個抽象策略類的子類,用一句話來說,就是:“準備一組演算法,并將每一個演算法封裝起來,使得它們可以互換”,
【此處的演算法,大家可以理解為解決業務需求的方法,】
對于這些概念大家理解起來或許有些抽象,耐心往下讀,相信大家肯定會有所識訓,
組成
- 環境(Context)角色:持有一個Strategy的參考,
- 抽象策略(Strategy)角色:這是一個抽象角色,通常由一個介面或抽象類實作,此角色給出所有的具體策略類所需的介面,
- 具體策略(ConcreteStrategy)角色:包裝了相關的演算法或行為,
理解
對于設計模式中的策略模式,大家眾多的解釋可能側重與解決if…else,switch-cas這種條件陳述句的優化,小編簡單談一下我在專案中實際應用和理解吧;對于策略模式按照上面給予的定義理解,是將多個業務節點具備的共同演算法再次頂層抽象為介面,處理不同業務需求時,則產生的行為不同,即具體行為由其實作類解決;注重詞:相同演算法,,頂層抽出,
再簡單舉例說明一下,比如作業的OA系統中,流程節點具體相同的功能:提交,回退,撤回等等(抽象策略類);但是每個流程節點所實作的功能不同(具體策略類);
實作
小編以我們日常生活中最常見的支付方式為例,解答策略模式的應用,
無論使用xiaomi,huawei,apple均存在相同的行為(演算法),例如:支付方式不同,客戶端享受的優惠力度不等,故我們將支付作為共同的介面抽象出來,
UML

抽象策略類
將支付作為共同演算法,頂層抽象,
/**
* @author wx
* @date 2021/03/05 1:50 下午
*/
public interface PayStrategy {
void pay(double money);
}
具體策略類
MiPAY
/**
* @author wx
* @date 2021/03/05 1:51 下午
*/
public class MiPayStrategy implements PayStrategy{
@Override
public void pay(double money) {
double payMoney = money * 0.87;
double discountMoney = money - payMoney;
System.out.println("使用Mi pay成功支付" + payMoney + "元,優惠" + discountMoney + "元");
}
}
HuaWeiPAY
/**
* @author wx
* @date 2021/03/05 1:50 下午
*/
public class HuaWeiPayStrategy implements PayStrategy{
@Override
public void pay(double money) {
double payMoney = money * 0.85;
double discountMoney = money - payMoney;
System.out.println("使用HuaWei pay成功支付" + payMoney + "元,優惠" + discountMoney + "元");
}
}
ApplePAY
/**
* @author wx
* @date 2021/03/05 1:52 下午
*/
public class ApplePayStrategy implements PayStrategy{
@Override
public void pay(double money) {
double payMoney = money * 0.82;
double discountMoney = money - payMoney;
System.out.println("使用Apple pay成功支付" + payMoney + "元,優惠" + discountMoney + "元");
}
}
環境類
供客戶端呼叫,并選擇具體策略
/**
* @author wx
* @date 2021/03/05 1:53 下午
*/
public class PayContext {
//依賴策略介面屬性
private PayStrategy payStrategy;
public void setPayStrategy(PayStrategy payStrategy) {
this.payStrategy = payStrategy;
}
/**
* 提供外部訪問方法
* @param money
*/
public void payMoney(double money) {
payStrategy.pay(money);
}
}
客戶端
客戶端則已知選擇的支付方式,可以服務端依據不同支付策略選擇折扣,
/**
* @author wx
* @date 2021/03/05 1:59 下午
*/
public class PayClient {
public static void main(String[] args) {
//創建支付背景關系
PayContext payContext = new PayContext();
//創建支付策略,客戶端已知存在具體策略
PayStrategy miPayStrategy = new MiPayStrategy();
payContext.setPayStrategy(miPayStrategy);
payContext.payMoney(100);
System.out.println("-------改變支付策略--------");
PayStrategy applePayStrategy = new ApplePayStrategy();
payContext.setPayStrategy(applePayStrategy);
payContext.payMoney(100);
}
}
執行結果:

理解了策略模式的使用,下面簡單談談該模式的優點和缺點:
- 優點:
1.毫不疑問復合設計模式中的開閉原則,新增支付方式則擴展策略類即可,無須改動其他策略類的實作;
2.消除if-else類似的判斷陳述句,整合代碼結構,符合代碼整潔之道; - 缺點:
1.從類的數量上而言,若策略選擇很多,則造成策略類數量增加;
2.所有策略類都需要對外暴露,即客戶端必須知道所有的策略類,并自行決定使用哪一個策略類,故不得不向客戶暴露具體的實作,
類比其他模式
策略模式和狀態模式:
一、執行方式:
策略模式:客戶端策略條件選擇只執行一次;
狀態模式:隨著實體引數(物件實體的狀態)的改變不停地更改執行模式,
簡言之,策略模式只是在物件初始化的時候更改執行模式,而狀態模式是根據物件實體的周期時間而動態地改變物件實體的執行模式,
二、環境類
策略模式:環境類自己選擇一個具體策略類,具體策略類無須關心環境類 ;
狀態模式:環境類由于外在因素需要放進一個具體狀態中,以便通過其方法實作狀態的切換 ,因此環境類和狀態類之間存在一種雙向的關聯關系,
簡言之,使用策略模式時客戶端需要知道所選的具體策略是哪一個;
而使用狀態模式時, 客戶端無須關心具體狀態 ,環境類的狀態會根據用戶的操作自動轉換,
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/266706.html
標籤:其他
