策略模式的特點是不管過程怎麼樣，結果都是一樣的。不管乘坐飛機還是火車，最後都會到達北京；不管哪種支付方式，最終都會支付成功。過程不一樣，結果都一樣。
支付時，會有很多引數，很多邏輯，經常會遇到一種支付方式，上百行的**，而且還需要很好的把控事務。如果多種支付方式，**也會成倍的**。維護起來相當難受。
**如下（示例）：
public resultdata makeorder(@requestbody order order)else if (order.gettype=="jd")else if (order.gettype=="yunshanfu")
// 傳送到mq，進行廣播。
return this.ok(order);
}相信**肯定會很多，而且if/else來處理會顯得**很雜亂。或者有通過增加介面來減少if/else
public resultdata makeorder(@requestbody order order)
public resultdata makeorder(@requestbody order order)
現在邏輯少，**不會顯得雜亂，如果有很多種支付方式呢？**會顯得很雜亂，而且擴充套件受限。擴充套件：設計模式內容聚合
**如下（入口）：
private orderservice orderservice;
// 商品id
// 支付型別
public resultdata makeorder(long goodsid,string type)
public enum paytype
//通過get方法獲取支付方式
public payment get()
public static paytype getbycode(string paytype)
}return null;}}
public inte***ce paymentpublic class alipay implements payment
}
public class wechatpay implements payment
}
但是，其實這樣一看，哇，使用策略模式，建立了好多類，好麻煩的樣子，還是使用if/else**少一點，但是長遠來說，支付的邏輯一定是錯綜複雜，通過策略模式可以更加友好的進行擴充套件。
但是if/else進行擴充套件，**會比較冗餘，如果本來就沒幾行**，缺強制使用策略模式，無意是畫蛇添足。
推薦好文
強大，10k+點讚的 springboot 後台管理系統竟然出了詳細教程！
分享一套基於springboot和vue的企業級中後台開源專案，**很規範！
能掙錢的，開源 springboot **系統，功能超全，超漂亮！
設計模式 策略模式 支付案例
設計模式 模板模式 jdbc案例 設計模式 介面卡模式 登入案例 設計模式 委派模式 登入案例 支付時，會有很多引數，很多邏輯，經常會遇到一種支付方式，上百行的 而且還需要很好的把控事務。如果多種支付方式，也會成倍的 維護起來相當難受。如下 示例 makeorder public resultdat...
乙個策略模式的實現
今天執著看 大話模式設計 又學到乙個很重要的東東 第二種模式 策略模式 我們來看乙個關於收銀系統 它的介面是這樣的 和以前一樣我們選來看看業務邏輯層的 using system using system.collections.generic using system.text namespace ...
乙個簡單工廠模式小案例
最基本的計算器功能也可以通過工廠模式實現 用到了繼承和多型 抽出乙個主類運算類,為了符合開閉原則,對修改關閉,對擴充套件開放 在該類中定義兩個做運算的變數a和b 提供乙個etresult方法 新建四個算術運算類繼承運算類,重寫getresult方法,根據自己的型別返回需要的結果 重寫result方法...