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