Java: 別在再滿屏的 if- else 了，試試策略模式，真香！！
你還在寫滿屏的 if/ else/ switch 之類的判斷邏輯嗎？
棧長在開發人員的代碼中看過太多這樣的低級代碼了，真的太 low，極不好維護，本文棧長就教你如何用策略模式幹掉 if/ else/ switch，讓你的代碼更優雅。
什麼是策略模式？
比如說對象的某個行爲，在不同場景中有不同的實現方式，這樣就可以將這些實現方式定義成一組策略，每個實現類對應一個策略，在不同的場景就使用不同的實現類，並且可以自由切換策略。
策略模式結構圖如下：
策略模式需要一個策略接口，不同的策略實現不同的實現類，在具體業務環境中僅持有該策略接口，根據不同的場景使用不同的實現類即可。
面向接口編程，而不是面向實現。
策略模式的優點：
1、幹掉繁瑣的 if、switch 判斷邏輯；
2、代碼優雅、可複用、可讀性好；
3、符合開閉原則，擴展性好、便於維護；
策略模式的缺點：
1、策略如果很多的話，會造成策略類膨脹；
2、使用者必須清楚所有的策略類及其用途；
策略模式實戰
舉個實際的例子，XX 公司是做支付的，根據不同的客戶類型會有不同的支付方式和支付產品，比如：信用卡、本地支付，而本地支付在中國又有微信支付、支付寶、雲閃付、等更多其他第三方支付公司，這時候策略模式就派上用場了。
傳統的 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、定義各種策略
定義各種支付策略，微信支付、支付寶、雲閃付等支付實現類都實現這個接口。
微信支付實現：
/**
* 微信支付
* @author: 棧長
* @from: 公衆號Java技術棧
*/
@Service("WechatPay")
public class WechatPay implements IPayment {
@Override
public PayResult pay(Order order) {
return new PayResult("微信支付成功");
}
}支付寶實現：
/**
* 支付寶
* @author: 棧長
* @from: 公衆號Java技術棧
*/
@Service("Alipay")
public class Alipay implements IPayment {
@Override
public PayResult pay(Order order) {
return new PayResult("支付寶支付成功");
}
}雲閃付實現：
/**
* 銀聯雲閃付
* @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，這樣更貼近業務。Spring 基礎教程就不介紹了，大家可以關注公衆號 Java 技術棧，回覆：spring，歷史教程我都整理好了。
3、使用策略
有的文章使用了枚舉、HashMap 的方式來根據策略名稱映射策略實現類 ，這樣是沒有問題，但在使用了 Spring 框架的項目還是有點多此一舉，完全可以發揮 Spring 框架的優勢，使用 Bean 名稱就能找到對應的策略實現類了。
參考示例代碼如下：
/**
* 支付服務
* @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);
// 根據支付類型獲取對應的策略 bean
IPayment payment = applicationContext.getBean(order.getPaymentType(), IPayment.class);
// 開始支付
PayResult payResult = payment.pay(order);
return payResult;
}
}看示例代碼，我並沒有像策略模式結構圖中那樣新建一個 Context 類持有策略接口，那是標準的策略模式，其實道理是一樣的，關鍵是怎麼施放策略。
測試一下：
http://localhost:8080/pay?amount=8800&paymentType=WechatPay
測試 OK，傳入不同的支付方式會調用不同的策略。
本節教程所有實戰源碼已上傳到這個倉庫：https://github.com/javastacks/javastack
策略模式在 JDK 中的應用
現在我們知道如何使用策略模式了，現在我們再看看 JDK 哪些地方運用了策略模式呢。
1、線程池中的拒絕策略
線程池的構造中有一個拒絕策略參數，默認是默認拒絕策略：
其實這就是一個策略接口：
下面有幾種拒絕策略的實現：
image-20210329161322406
在創建線程池的時候，就可以傳入不同的拒絕策略，這就是 JDK 中策略模式的經典實現了。
2、比較器
JDK 中大量使用了 Comparator 這個策略接口：
策略接口有了，但策略需要開發人員自己定。
集合排序我們比較熟悉的了，不同的排序規則其實就是不同的策略：
這個策略模式使用了函數式編程接口，比較規則使用匿名內部類或者 Lambda 表達式就搞定了，不需要每個規則定義一個實現類，這樣就大量省略策略類了。
這個策略模式可能藏的比較深，但也是 JDK 中經典的策略模式的應用了。
不限於這兩個，其實還有更多，你還知道別的麼？歡迎留言分享……
所以說，策略模式就在你身邊，你一直都在用，但可能沒有發覺。。
總結
使用策略模式，我們可以輕鬆幹掉大量的 if/ else，代碼也更優雅，還能很靈活的擴展。
像本文中支付的案例，後面我們想添加、刪除多少個支付方式都不用修改現有的代碼，所以就不會影響現有的業務，真正做到對擴展開放，對修改關閉。
當然，完全乾掉 if/ else 是不可能的，不能過度設計，不能爲了使用設計模式而使用設計模式，否則適得其反。但是，我們每個程序員都需要掌握策略模式，做到在系統中靈活駕馭，這樣才能寫出更優雅、高質量的代碼。
本節教程所有實戰源碼已上傳到這個倉庫：
https://github.com/javastacks/javastack
好了，今天的分享就到這裏了，後面棧長我會更新其他設計模式的實戰文章，公衆號 Java 技術棧第一時間推送。Java 技術棧《設計模式》系列文章陸續更新中，請大家持續關注哦！
最後，覺得我的文章對你用收穫的話，動動小手，給個在看、轉發，原創不易，棧長需要你的鼓勵。
版權申明：本文系公衆號 "Java 技術棧" 原創，原創實屬不易，轉載、引用本文內容請註明出處，禁止抄襲、洗稿，請自重，尊重他人勞動成果和知識產權。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/PPX5xDiJJO7WRjIwJfaxPg