再一次实战策略模式，太好用了

前言

之前做三方支付系统的时候经常用到策略模式&＃xff0c;比如用户会选择不同的支付方式&＃xff0c;不同的支付方式又有不同的实现方法或银行接口调用。

现在做物联网系统&＃xff0c;基于MQTT协议&＃xff08;TCP层面的协议&＃xff09;来传输数据&＃xff0c;根据不同的请求&＃xff08;不同的Topic&＃xff09;处理不同的业务逻辑&＃xff0c;也同样用到策略模式。

顿时感觉策略模式非常好用&＃xff0c;而且结合Spring的实例化和注入功能&＃xff0c;更加方便了。

今天就聊聊基于Spring&＃xff08;Boot&＃xff09;下策略模式的使用。

未使用策略模式时的处理

以物联网为例大家可能不够熟悉&＃xff0c;下面就以支付场景为例。比如在支付的过程中我们可能会选择微信支付、支付宝支付或银卡支付。同时&＃xff0c;银行卡又分不同银行&＃xff0c;这里统一为银行卡。

最简单直接的代码实现形式如下&＃xff1a;

public void pay(String payType){if("alipay".equals(payType)){System.out.println("支付宝");}else if("wechatPay".equals(payType)){System.out.println("微信支付");} else if("bank".equals(payType)){System.out.println("银行卡支付");}
}


这样对照设计模式&＃xff0c;通常不符合两个原则&＃xff1a;单一职责原则和开闭原则。

我们会发现当前类&＃xff08;或方法&＃xff09;不处理了多个业务的功能&＃xff0c;一旦任何一个支付方式的修改都可能会影响到其他的支付方式。同时&＃xff0c;无法做到对扩展开放&＃xff0c;对修改关闭。新增其他支付方式时同样要修改ifelse判断&＃xff0c;影响到其他的业务逻辑。

而策略模式通常就是解决这种有很多ifelse处理逻辑&＃xff0c;从而提高代码的可维护性、可扩展性和可读性。

策略模式的轮廓

在对上述代码进行改造之前&＃xff0c;先来了解一下策略模式的基本组成。

策略模式&＃xff08;Strategy&＃xff09;&＃xff0c;定义了一组算法&＃xff0c;将每个算法都封装起来&＃xff0c;并且使它们之间可以互换。

策略模式通常有以下几部分组成&＃xff1a;

• Strategy策略类&＃xff0c;用于定义所有支持算法的公共接口&＃xff1b;
• ConcreteStrategy具体策略类&＃xff0c;封装了具体的算法或行为&＃xff0c;继承于Strategy。
• Context上下文&＃xff0c;用一个ConcreteStrategy来配置&＃xff0c;维护一个对Strategy对象的引用&＃xff1b;
• StrategyFactory策略工厂类&＃xff0c;用于创建策略类的具体实现&＃xff1b;通常此部分可省略&＃xff0c;看具体情况。比如后续实例中通过Spring的依赖注入机制实现了策略类的实例化。

用类图来表示&＃xff08;省略策略工厂类&＃xff09;如下图&＃xff1a;

基于Spring的策略模式实现

目前在实践中通常都是基于Spring的特性来实现策略模式&＃xff0c;这里就以此为例来进行讲解。

策略类定义

上面已经提到&＃xff0c;策略类用于定义功能的接口&＃xff0c;对于支付场景则可命名为PaymentService或PaymentStrategy。

public interface PaymentService {/*** 支付*/PayResult pay(Order order);
}


同时提供该策略类的不同实现类&＃xff1a;AlipayService、WeChatPayService、BankPayService。

&＃64;Service("alipay")
public class AlipayService implements PaymentService {&＃64;Overridepublic PayResult pay(Order order) {System.out.println("Alipay");return null;}
}


&＃64;Service("wechatPay")
public class WeChatPayService implements PaymentService {&＃64;Overridepublic PayResult pay(Order order) {System.out.println("WeChatPay");return null;}
}


&＃64;Service("bank")
public class BankPayService implements PaymentService {&＃64;Overridepublic PayResult pay(Order order) {System.out.println("BankPay");return null;}
}


具体实现的实例化&＃xff0c;可以通过一个PaymentFactory来进行构建存储&＃xff0c;也可以直接利用&＃64;Autowired形式注入到Context的List或Map当中。

PaymentFactory的实现如下&＃xff1a;

public class PaymentFactory {private static final Map payStrategies &＃61; new HashMap<>();static {payStrategies.put("alipay", new AlipayService());payStrategies.put("wechatPay", new WeChatPayService());payStrategies.put("bank", new BankPayService());}public static PaymentService getPayment(String payType) {if (payType &＃61;&＃61; null) {throw new IllegalArgumentException("pay type is empty.");}if (!payStrategies.containsKey(payType)) {throw new IllegalArgumentException("pay type not supported.");}return payStrategies.get(payType);}
}


通过static静态代码块来初始化对应的策略实现类&＃xff0c;然后提供一个getPayment方法&＃xff0c;根据支付类型来获取对应的服务。当然&＃xff0c;通过static初始化的代码块是单例的无状态的&＃xff0c;如果需要有状态的类则getPayment方法&＃xff0c;每次都需要new一个新的对象。

public static PaymentService getPayment1(String payType) {if (payType &＃61;&＃61; null) {throw new IllegalArgumentException("pay type is empty.");}if ("alipay".equals(payType)) {return new AlipayService();} else if ("wechatPay".equals(payType)) {return new WeChatPayService();} else if ("bank".equals(payType)) {return new BankPayService();}throw new IllegalArgumentException("pay type not supported.");
}


Context上下文

Context上下文角色&＃xff0c;也叫Context封装角色&＃xff0c;起承上启下的作用&＃xff0c;屏蔽高层模块对策略、算法的直接访问&＃xff0c;封装可能存在的变化。

上面通过工厂的形式创建策略类的实现类&＃xff0c;当然也可以直接通过&＃64;Autowired注入到Context上下文中。

&＃64;Component
public class PaymentStrategy {&＃64;Autowiredprivate final Map payStrategies &＃61; new HashMap<>();public PaymentService getPayment(String payType) {if (payType &＃61;&＃61; null) {throw new IllegalArgumentException("pay type is empty.");}if (!payStrategies.containsKey(payType)) {throw new IllegalArgumentException("pay type not supported.");}return payStrategies.get(payType);}
}


上面通过&＃64;Autowired注解&＃xff0c;将通过&＃64;Service实例化的PaymentService实现类&＃xff0c;注入到map当中&＃xff0c;其中key为实例化类的名称&＃xff0c;value为具体的实例化类。

上面的getPayment代码与PaymentFactory中一致。当然&＃xff0c;还可以在PaymentStrategy中封装一个pay方法&＃xff0c;这样&＃xff0c;客户端直接注入PaymentStrategy类调用pay方法即可。

public PayResult pay(String payType,Order order){PaymentService paymentService &＃61; this.getPayment(payType);return paymentService.pay(order);
}


改进方案

通过上面的代码基本上已经实现了策略模式&＃xff0c;此时当新增加一个支付通道时&＃xff0c;已经不用修改PaymentStrategy相关的代码&＃xff0c;只用新增一个实现PaymentService接口的类即可。

但在接口定义这里&＃xff0c;还是有优化空间的。比如&＃xff0c;这里判断是通过Bean的名称来判断的&＃xff0c;但某些情况下判断可能比较复杂或可能会同时执行多个Service。此时&＃xff0c;就可以对PaymentService接口进行改进&＃xff0c;新增一个检验是否支持该功能的判断方法。

public interface PaymentService {boolean isSupport(Order order);/*** 支付*/PayResult pay(Order order);
}


由实现类来具体实现isSupport方法&＃xff0c;判断自己支持哪些功能。

同时&＃xff0c;上下文类也可以进一步利用Java8提供的Steam特性进行处理&＃xff1a;

&＃64;Component
public class PaymentStrategy {/*** 此处用&＃64;Autowired将所有实例注入为List。*/&＃64;Autowiredprivate List paymentServices;public void pay(Order order) {PaymentService paymentService &＃61; paymentServices.stream().filter((service) -> service.isSupport(order)).findFirst().orElse(null);if (paymentService !&＃61; null) {paymentService.pay(order);} else {throw new IllegalArgumentException("pay type not supported.");}}
}


通过进一步改造&＃xff0c;程序变得更加灵活了。

小结

通过上面的代码实现&＃xff0c;可以看出接口类只负责业务策略的定义&＃xff0c;策略的具体实现可以单独放在实现类中也可以利用Spring的特性进行管理&＃xff0c;Context上下文类负责业务逻辑的编排。

通过策略模式&＃xff08;或变种&＃xff09;的应用&＃xff0c;实现了面向接口而非实现编程&＃xff0c;满足了职责单一、开闭原则&＃xff0c;从而达到了功能上的高内聚低耦合、提高了可维护性、扩展性以及代码的可读性。

最后&＃xff0c;对于设计模式&＃xff0c;只有在实践中不断的使用采用更加印象深刻。同时&＃xff0c;在实现的过程中我们也并不一定非要拘泥于设计模式本身&＃xff0c;也可以结合所使用的框架进行变种处理。