|
你還在寫滿屏的 if/ else/ switch 之類的判斷邏輯嗎？這樣的低級(jí)代碼了，不僅 low，且極不好維護(hù)，用策略模式干掉 if/ else/ switch，讓你的代碼更優(yōu)雅。
什么是策略模式？
比如說對(duì)象的某個(gè)行為，在不同場景中有不同的實(shí)現(xiàn)方式，這樣就可以將這些實(shí)現(xiàn)方式定義成一組策略，每個(gè)實(shí)現(xiàn)類對(duì)應(yīng)一個(gè)策略，在不同的場景就使用不同的實(shí)現(xiàn)類，并且可以自由切換策略。
策略模式需要一個(gè)策略接口，不同的策略實(shí)現(xiàn)不同的實(shí)現(xiàn)類，在具體業(yè)務(wù)環(huán)境中僅持有該策略接口，根據(jù)不同的場景使用不同的實(shí)現(xiàn)類即可。
面向接口編程，而不是面向?qū)崿F(xiàn)。
策略模式的優(yōu)點(diǎn)：
1、干掉繁瑣的 if、switch 判斷邏輯；
2、代碼優(yōu)雅、可復(fù)用、可讀性好；
3、符合開閉原則，擴(kuò)展性好、便于維護(hù)；
策略模式的缺點(diǎn)：
1、策略如果很多的話，會(huì)造成策略類膨脹；
2、使用者必須清楚所有的策略類及其用途；
策略模式實(shí)戰(zhàn)
舉個(gè)實(shí)際的例子，XX 公司是做支付的，根據(jù)不同的客戶類型會(huì)有不同的支付方式和支付產(chǎn)品，比如：信用卡、本地支付，而本地支付在中國又有微信支付、支付寶、云閃付、等更多其他第三方支付公司，這時(shí)候策略模式就派上用場了。
傳統(tǒng)的 if/ else/ switch 等判斷寫法大家都會(huì)寫，這里就不貼代碼了，直接看策略模式怎么搞！
1、定義策略接口
定義一個(gè)策略接口，所有支付方式的接口。
策略接口：
/**
* 支付接口
* @author: 棧長
* @from: 公眾號(hào)Java技術(shù)棧
*/
public interface IPayment {
/**
* 支付
* @param order
* @return
*/
PayResult pay(Order order);
}
訂單信息類：
/**
* 訂單信息
* @author: 棧長
* @from: 公眾號(hào)Java技術(shù)棧
*/
@Data
public class Order {
/**
* 金額
*/
private int amount;
/**
* 支付類型
*/
private String paymentType;
}
返回結(jié)果類：
/**
* @author: 棧長
* @from: 公眾號(hào)Java技術(shù)棧
*/
@Data
@AllArgsConstructor
public class PayResult {
/**
* 支付結(jié)果
*/
private String result;
}
2、定義各種策略
定義各種支付策略，微信支付、支付寶、云閃付等支付實(shí)現(xiàn)類都實(shí)現(xiàn)這個(gè)接口。
微信支付實(shí)現(xiàn)：
/**
* 微信支付
* @author: 棧長
* @from: 公眾號(hào)Java技術(shù)棧
*/
@Service("WechatPay")
public class WechatPay implements IPayment {
@Override
public PayResult pay(Order order) {
return new PayResult("微信支付成功");
}
}
支付寶實(shí)現(xiàn)：
/**
* 支付寶
* @author: 棧長
* @from: 公眾號(hào)Java技術(shù)棧
*/
@Service("Alipay")
public class Alipay implements IPayment {
@Override
public PayResult pay(Order order) {
return new PayResult("支付寶支付成功");
}
}
云閃付實(shí)現(xiàn)：
/**
* 銀聯(lián)云閃付
* @author: 棧長
* @from: 公眾號(hào)Java技術(shù)棧
*/
@Service("UnionPay")
public class UnionPay implements IPayment {
@Override
public PayResult pay(Order order) {
return new PayResult("云閃付支付成功");
}
}
這里我把所有支付方式類都用 @Service 注解生成 Bean 放入 Spring Bean 容器中了，在使用策略的時(shí)候就不用 new 支付對(duì)象了，可以直接使用 Bean，這樣更貼近業(yè)務(wù)。
3、使用策略
有的文章使用了枚舉、HashMap 的方式來根據(jù)策略名稱映射策略實(shí)現(xiàn)類 ，這樣是沒有問題，但在使用了 Spring 框架的項(xiàng)目還是有點(diǎn)多此一舉，完全可以發(fā)揮 Spring 框架的優(yōu)勢(shì)，使用 Bean 名稱就能找到對(duì)應(yīng)的策略實(shí)現(xiàn)類了。
參考示例代碼如下：
/**
* 支付服務(wù)
* @author: 棧長
* @from: 公眾號(hào)Java技術(shù)棧
*/
@RestController
public class PayService {
@Autowired
private ApplicationContext applicationContext;
/**
* 支付接口
* @param amount
* @param paymentType
* @return
*/
@RequestMapping("/pay")
public PayResult pay(@RequestParam("amount") int amount,
@RequestParam("paymentType") String paymentType) {
Order order = new Order();
order.setAmount(amount);
order.setPaymentType(paymentType);
// 根據(jù)支付類型獲取對(duì)應(yīng)的策略 bean
IPayment payment = applicationContext.getBean(order.getPaymentType(), IPayment.class);
// 開始支付
PayResult payResult = payment.pay(order);
return payResult;
}
}
看示例代碼，我并沒有像策略模式結(jié)構(gòu)圖中那樣新建一個(gè) Context 類持有策略接口，那是標(biāo)準(zhǔn)的策略模式，其實(shí)道理是一樣的，關(guān)鍵是怎么施放策略。
使用策略模式，我們可以輕松干掉大量的 if/ else，代碼也更優(yōu)雅，還能很靈活的擴(kuò)展。
像本文中支付的案例，后面我們想添加、刪除多少個(gè)支付方式都不用修改現(xiàn)有的代碼，所以就不會(huì)影響現(xiàn)有的業(yè)務(wù)，真正做到對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。
當(dāng)然，完全干掉 if/ else 是不可能的，不能過度設(shè)計(jì)，不能為了使用設(shè)計(jì)模式而使用設(shè)計(jì)模式，否則適得其反。但是，我們每個(gè)程序員都需要掌握策略模式，做到在系統(tǒng)中靈活駕馭，這樣才能寫出更優(yōu)雅、高質(zhì)量的代碼。
 |
