还在if else else if ? 看看策略模式吧-CSDN博客

本文链接：https://blog.csdn.net/weixin_44912855/article/details/117706343

本文介绍了如何通过策略模式来改进充满ifelse的代码，以提升代码的可读性和可扩展性。示例中展示了如何定义支付接口和实现类，使得新增支付方式时无需修改原有代码。此外，还给出了订单处理的策略模式应用，通过不同的实现类处理不同类型的订单，保持模块间的独立性。

摘要由CSDN通过智能技术生成

别再大量的if else了, 代码太简陋了, 可读性太差了.

策略模式的定义

....

简单来说每个模块相互独立互不影响提高代码的可扩展性 !

举栗子, 如下烂代码

if ("花呗支付".equals(type)) {

	// 花呗支付的业务逻辑处理

} else if ("微信支付".equals(type)) {

	// 微信支付业务逻辑

} else if ("云闪付".equals(type)) {

	// 云闪付支付业务逻辑

} else if ("...".equals(type)) {
			
    // ....
}

思考: 可以定义一个支付接口, 支付方法, 不同的支付方式写不同的实现类, 互不干扰, 互不影响, 以后添加新的支付方式, 只需添加新的实现类实现支付接口, 重写他的支付方法即可, 无需改动之前写的代码.

正好今天敲代码的时候使用到了该设计模式, 简单分享一下

定义接口以及实现类

举例子。不同类型的订单对应不同的发票处理

每个实现类都会处理自己的业务, 互不干扰, 相互隔离, 比如如下两个实现类实现了相同接口处理不同的业务

public interface FpHandlerService {

    void handler(List<OrderCompleteVO2> list, ArrayList<FpVO> result);

    /**
     * 软件类型处理
     */
    @Service("fpHandler:1")
    class FpSoftwareServiceImpl implements FpHandlerService {
        @Override
        public void handler(List<OrderCompleteVO2> list, ArrayList<FpVO> result) {
        
        }
    }

    /**
     * 硬件类型处理
     */
    @Service("fpHandler:2")
    class FpHardwareServiceImpl implements FpHandlerService {
        @Override
        public void handler(List<OrderCompleteVO2> list, ArrayList<FpVO> result) {
          
        } 
    }
}

使用

Map<String, List<OrderCompleteVO2>> listMap = orderList.stream().collect(Collectors.groupingBy(OrderCompleteVO2::getOrderType));
        listMap.forEach((k, v) -> {
            String beanName = "fpHandler:" + k; // k订单类型 1还是2 拼接前缀找到对应的bean处理业务
            FpHandlerService fpHandlerService = beanFactory.getBean(beanName, FpHandlerService.class);
            fpHandlerService.handler(v, result);
        });

是不是比大量的if else 简洁多了~

把每个不同的模块抽取出来, 通过bean的名称获取接口的实现类, 执行方法