什么是設計模式?
- 設計模式是軟體開發人員在軟體開發程序中面臨的一般問題的解決方案,這些解決方案是眾多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的,
- 設計模式是一套被反復使用的、多數人知曉的、經過分類編目的、代碼設計經驗的總結,使用設計模式是為了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性
今天我們來說策略模式,何為策略模式?讓我們先看看以下示例代碼
這里我們拿支付方式來舉例
工程結構如下:

這是我們的支付介面,定義了一個支付的方法 根據不同的支付型別給予不同的優惠
public interface Pay {
/**
* @param skuPrice 提交的金額
* @return
*/
BigDecimal payment(Integer,BigDecimal skuPrice);
}
我們來看看這個支付介面的實作類
public class PayService implements Pay {
public BigDecimal payment(Integer type,BigDecimal skuPrice) {
// 1. 支付寶 優惠0.7元
if (1 == type) {
return skuPrice.subtract(new BigDecimal(0.7));
}
// 2. 微信支付 優惠0.3
if (2 == type) {
return skuPrice.subtract(new BigDecimal(0.3));
}
return skuPrice;//否則銀行卡支付原價
}
}
這種方式看似沒有什么問題,想要的功能也能為你實作,但一旦優惠條件的演算法難度上升導致代碼量劇增,大量的if else陳述句會使整個程式代碼看起來又長又臭,而且對于產品的擴展性極其不友好
思考:如何避免使用if陳述句并能使程式根據不同的支付型別給予不同的優惠?

就是我們今天的主角 策略模式!
為什么需要策略模式?
- 指物件有某個行為,但是在不同的場景中,該行為有不同的實作演算法
- 可以理解為見風使舵?根據不同的客戶而選擇不同服務 而這些,作為客戶他們并不需要知曉
- 像現在我們說的這個例子,客戶都需要支付 但支付的方式不同 所以不同的支付方式都需要一套不同規則對應的演算法
切入正題!改造我們的代碼
首先,使用不同的支付方式實作支付介面
- 微信支付
public class WeChatPay implements Pay {
/**
* 微信支付10元+ 優惠0.7
* @param skuPrice 提交的金額
* @return
*/
public BigDecimal payment(BigDecimal skuPrice) {
//大于10元就優惠
if (skuPrice.compareTo(new BigDecimal(10)) >= 0)
return skuPrice.subtract(new BigDecimal(0.7));//回傳優惠價
return skuPrice;//回傳原價
}
}
- 支付寶支付
public class AliPay implements Pay {
public BigDecimal payment(BigDecimal skuPrice) {
if (skuPrice.compareTo(new BigDecimal(10)) >= 0)
return skuPrice.subtract(new BigDecimal(0.3));//回傳優惠價
return skuPrice;
}
}
- 銀行卡支付
public class BankPay implements Pay {
/**
* @param skuPrice 提交的金額
* @return
*/
public BigDecimal payment(BigDecimal skuPrice) {
return skuPrice;//銀行卡支付無優惠
}
}
策略類
public class PayStrategy<T> {
private Pay pay;
public PayStrategy (Integer i) {
if (i == 1) {
pay= new WeChatPay();
} else if (i == 2) {
pay = new AliPay();
} else {
pay = new BankPay();
}
}
public BigDecimal payment(BigDecimal skuPrice) {
return pay.payment(skuPrice);
}
}
來康康測驗結果
@Test
public void test() {
PayStrategy pay = new PayStrategy(1);//1=微信支付
BigDecimal bigDecimal = pay.payment(new BigDecimal(20));
logger.info("測驗結果:支付金額 {}",bigDecimal);
}

經測驗我們的策略模式成功了,但是大家有沒有發現個問題在我們的策略類中有一段這樣的代碼

這是啥玩意? 如果按照這種寫法 如果產品多增加一種支付型別那么就意味著你要再增加if else! 然后不停的new哦~ 嘿嘿嘿. 這非常的齷齪!
作為俺們村的村草我是絕對不允許這種事情發生 咳咳~
我們可以把創建實體的作業交個Spring 大大簡化開發,讓我們看下面的代碼
新建一個支付型別列舉
public enum PayEnum {
WeChatPay,
PayStrategy,
AliPay;
}
在我們的支付介面實作類上標注@component注解 將物件加載進入Springbean中 起別名為類名 例如:
@Component("WeChatPay")
public class WeChatPay implements Pay {
@Component("BankPay")
public class BankPay implements Pay {
@Component("AliPay")
public class AliPay implements Pay {
改造策略類
@Component
public class PayStrategy {
private Pay pay;
private Map<String,Pay> map;
public void setStrategy(PayEnum strategy) {
pay = map.get(strategy.toString());
System.out.println("pay == " + pay);
}
/**
* 工廠初始化注入map
*/
public PayStrategy(Map<String,Pay> map) {
this.map = map;
}
public BigDecimal payment(BigDecimal sku) {
return pay.payment(sku);
}
}
策略工廠,說明一下該方法的作用,可見下列方法的有一個map引數,它是如何注入的呢?
- 如果找到了 Pay的實作類spring就會以String == 類名(別名) Pay = 自動查找實作類物件
@Component
public class PayStrategyFactory {
@Bean
public PayStrategy payStrategy(Map<String,Pay> map) {
return new PayStrategy(map);
}
}
因為spring的默認機制,默認是單例模式 我們并不需要擔心map是否會失效,在策略類中定義的map為我們實作了實作類的單例 讓我們來測驗一下
@ComponentScan
public class Application {
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(Application.class);//初始化IOC容器
try {
PayStrategy payStrategy = ctx.getBean(PayStrategy.class);
payStrategy.setStrategy(PayEnum.WeChatPay);
System.out.println("支付價格為 == " + payStrategy.payment(new BigDecimal(20)).setScale(2,BigDecimal.ROUND_DOWN));
payStrategy.setStrategy(PayEnum.AliPay);
System.out.println("支付價格為 == " + payStrategy.payment(new BigDecimal(20)).setScale(2,BigDecimal.ROUND_DOWN));
payStrategy.setStrategy(PayEnum.WeChatPay);
System.out.println("支付價格為 == " + payStrategy.payment(new BigDecimal(20)).setScale(2,BigDecimal.ROUND_DOWN));
payStrategy.setStrategy(PayEnum.BankPay);
System.out.println("支付價格為 == " + payStrategy.payment(new BigDecimal(20)).setScale(2,BigDecimal.ROUND_DOWN));
} catch (Exception e) {
e.printStackTrace();
}
}
}
可以看到我們在使用相同列舉時候 拿到的都是同一個物件,這就完成了單例模式

同學,你學廢了嘛,設計模式深擼起來會感覺非常奇妙,在上述代碼中還有些許不完美,讓我們一起進步吧,這片文章要是對你有幫助記得點個贊喲
每日進步一點點,Day Day Up
轉載請註明出處,本文鏈接:https://www.uj5u.com/yidong/160245.html
標籤:其他
上一篇:Java~Thread的API是如何改變執行緒的狀態和分析解決生產者|消費者模型中的假死現象與wait條件改變例外
下一篇:java實驗報告9 面向介面編程
