如何优雅的用策略模式,取代臃肿的 if-else 嵌套,看这篇就够了

2023-10-11 01:10

本文主要是介绍如何优雅的用策略模式,取代臃肿的 if-else 嵌套,看这篇就够了,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

整理了一些Java方面的架构、面试资料(微服务、集群、分布式、中间件等),有需要的小伙伴可以关注公众号【程序员内点事】,无套路自行领取

精彩回顾:

  • 一口气说出 9种 分布式ID生成方式,面试官有点懵了
  • 后端程序员不得不会的 Nginx 转发匹配规则
  • 基于 Java 实现的人脸识别功能(附源码)
  • 一口气说出 6种 @Transactional 注解失效场景
  • 干货推荐!程序员必备的13个 免费技术电子书网站

一、传统的实现方式

先说一下具体的需求:公司推广入口很多,每一个下单来源在下单时都做特殊的逻辑处理,可能每两天就会加一个来源。

那么按照传统的实现方式代码就是如下:

public class OrderServiceImpl implements IOrderService {@Overridepublic String handle(OrderDTO dto) {String type = dto.getType();if ("1".equals(type)) {return "处理普通订单";} else if ("2".equals(type)) {return "处理团购订单";} else if ("3".equals(type)) {return "处理促销订单";}return null;}
}

为什么非得写的这么臃肿?很多同事会说:“哎呀,没办法呀,业务催的紧,这样开发效率快省事”。的确是句大实话,很多时候业务方确实像催命鬼一样的让你赶工期,想快速实现功能,这样写是最好的选择。

上边的代码看似还算清晰,可如果我告诉你公司订单来源有上百种,你想象一下那种臃肿的if-else,去翻代码时是什么感受?

二、策略模式的实现方式

策略模式是oop中最著名的设计模式之一,是对方法行为的抽象,可以归类为行为设计模式,也是oopinterface经典的应用。其特点简单又实用,是我最喜欢的模式之一。

策略模式定义了一个拥有共同行为的算法族,每个算法都被封装起来,可以互相替换,独立于客户端而变化。

不少人说:Java的设计模式背了很多,可日常还不就是写if-else的业务,根本就不用到。其实不是用不到是没有用到合适的位置!

1、策略模式的使用场景:
  • 针对同一问题的多种处理方式,仅仅是具体行为有差别时;
  • 需要安全地封装多种同一类型的操作时;
  • 同一抽象类有多个子类,而客户端需要使用if-else 或者 switch-case 来选择具体子类时。

这个是用策略模式修改后代码:

@Component
@OrderHandlerType(16)
public class DispatchModeProcessor extends AbstractHandler{@Autowiredprivate OrderStencilledService orderStencilledService;@Overridepublic void handle(OrderBO orderBO) {/*** 订单完结广播通知(1 - 支付完成)*/orderStencilledService.dispatchModeFanout(orderBO);/***  SCMS 出库单*/orderStencilledService.createScmsDeliveryOrder(orderBO.getPayOrderInfoBO().getLocalOrderNo());}
}

每个订单来源都有自己单独的逻辑实现类,而每次需要添加订单来源,直接新建实现类,修改@OrderHandlerType(16)的数值即可,再也不用去翻那几百行的if-lese,一劳永逸!

2、具体的实现过程:

1、定义一个标识订单来源的注解

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface OrderHandlerType {int value() default 0;
}

2、抽象出来一个具体的业务处理器

public abstract class AbstractHandler {abstract public void handle(OrderBO orderBO);
}

3、项目启动扫描 handler 入口

@Component
@SuppressWarnings({"unused","rawtypes"})
public class HandlerProcessor implements BeanFactoryPostProcessor {private String basePackage = "com.ecej.order.pipeline.processor";public static final Logger log = LoggerFactory.getLogger(HandlerProcessor.class);@Overridepublic void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {Map<Integer,Class> map = new HashMap<Integer,Class>();ClassScaner.scan(basePackage, OrderHandlerType.class).forEach(x ->{int type = x.getAnnotation(OrderHandlerType.class).value();map.put(type,x);});beanFactory.registerSingleton(OrderHandlerType.class.getName(), map);log.info("处理器初始化{}", JSONObject.toJSONString(beanFactory.getBean(OrderHandlerType.class.getName())));}
}

4、扫描需要用到的工具类

public class ClassScaner {private ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver();private final List<TypeFilter> includeFilters = new ArrayList<TypeFilter>();private final List<TypeFilter> excludeFilters = new ArrayList<TypeFilter>();private MetadataReaderFactory metadataReaderFactory = new CachingMetadataReaderFactory(resourcePatternResolver);/*** 添加包含的Fiter* @param includeFilter*/public void addIncludeFilter(TypeFilter includeFilter) {this.includeFilters.add(includeFilter);}/*** 添加排除的Fiter* @param includeFilter*/public void addExcludeFilter(TypeFilter excludeFilter) {this.excludeFilters.add(excludeFilter);}/*** 扫描指定的包,获取包下所有的Class* @param basePackage 包名* @param targetTypes 需要指定的目标类型,可以是pojo,可以是注解* @return Set<Class<?>>*/public static Set<Class<?>> scan(String basePackage,Class<?>... targetTypes) {ClassScaner cs = new ClassScaner();for (Class<?> targetType : targetTypes){if(TypeUtils.isAssignable(Annotation.class, targetType)){cs.addIncludeFilter(new AnnotationTypeFilter((Class<? extends Annotation>) targetType));}else{cs.addIncludeFilter(new AssignableTypeFilter(targetType));}}return cs.doScan(basePackage);}/*** 扫描指定的包,获取包下所有的Class* @param basePackages 包名,多个* @param targetTypes 需要指定的目标类型,可以是pojo,可以是注解* @return Set<Class<?>>*/public static Set<Class<?>> scan(String[] basePackages,Class<?>... targetTypes) {ClassScaner cs = new ClassScaner();for (Class<?> targetType : targetTypes){if(TypeUtils.isAssignable(Annotation.class, targetType)){cs.addIncludeFilter(new AnnotationTypeFilter((Class<? extends Annotation>) targetType));}else{cs.addIncludeFilter(new AssignableTypeFilter(targetType));}}Set<Class<?>> classes = new HashSet<Class<?>>();for (String s : basePackages){classes.addAll(cs.doScan(s));}return classes;}/*** 扫描指定的包,获取包下所有的Class* @param basePackages 包名* @return Set<Class<?>>*/public Set<Class<?>> doScan(String [] basePackages) {Set<Class<?>> classes = new HashSet<Class<?>>();for (String basePackage :basePackages) {classes.addAll(doScan(basePackage));}return classes;}/*** 扫描指定的包,获取包下所有的Class* @param basePackages 包名* @return Set<Class<?>>*/public Set<Class<?>> doScan(String basePackage) {Set<Class<?>> classes = new HashSet<Class<?>>();try {String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX+ ClassUtils.convertClassNameToResourcePath(SystemPropertyUtils.resolvePlaceholders(basePackage))+"/**/*.class";Resource[] resources = this.resourcePatternResolver.getResources(packageSearchPath);for (int i = 0; i < resources.length; i++) {Resource resource = resources[i];if (resource.isReadable()) {MetadataReader metadataReader = this.metadataReaderFactory.getMetadataReader(resource);if ((includeFilters.size() == 0 && excludeFilters.size() == 0)|| matches(metadataReader)) {try {classes.add(Class.forName(metadataReader.getClassMetadata().getClassName()));} catch (ClassNotFoundException ignore) {}}}}} catch (IOException ex) {throw new RuntimeException("I/O failure during classpath scanning", ex);}return classes;}/*** 处理 excludeFilters和includeFilters* @param metadataReader* @return boolean* @throws IOException*/private boolean matches(MetadataReader metadataReader) throws IOException {for (TypeFilter tf : this.excludeFilters) {if (tf.match(metadataReader, this.metadataReaderFactory)) {return false;}}for (TypeFilter tf : this.includeFilters) {if (tf.match(metadataReader, this.metadataReaderFactory)) {return true;}}return false;}
}

5、 根据类型实例化抽象类


@Component
public class HandlerContext {@Autowiredprivate ApplicationContext beanFactory;public  AbstractHandler getInstance(Integer type){Map<Integer,Class> map = (Map<Integer, Class>) beanFactory.getBean(OrderHandlerType.class.getName());return (AbstractHandler)beanFactory.getBean(map.get(type));}}

6、调用入口,我这里是接的MQ消息,会批量的处理多个订单来源

@Component
@RabbitListener(queues = "OrderPipelineQueue")
public class PipelineSubscribe{private final Logger LOGGER = LoggerFactory.getLogger(PipelineSubscribe.class);@Autowiredprivate HandlerContext HandlerContext;@Autowiredprivate OrderValidateService orderValidateService;@RabbitHandlerpublic void subscribeMessage(MessageBean bean){OrderBO orderBO = JSONObject.parseObject(bean.getOrderBO(), OrderBO.class);if(null != orderBO &&CollectionUtils.isNotEmpty(bean.getType())){for(int value:bean.getType()){AbstractHandler handler = HandlerContext.getInstance(value);handler.handle(orderBO);}}}
}

接收实体 MessageBean 类代码

public class MessageBean implements Serializable {private static final long serialVersionUID = 5454831432308782668L;private String cachKey;private List<Integer> type;private String orderBO;public MessageBean(List<Integer> type, String orderBO) {this.type = type;this.orderBO = orderBO;}
}
三、策略模式的优缺点
优点
  • 易于扩展,增加一个新的策略只需要添加一个具体的策略类即可,基本不需要改变原有的代码,符合开放封闭原则
  • 避免使用多重条件选择语句,充分体现面向对象设计思想 策略类之间可以自由切换,由于策略类都实现同一个接口,所以使它们之间可以自由切换
  • 每个策略类使用一个策略类,符合单一职责原则 客户端与策略算法解耦,两者都依赖于抽象策略接口,符合依赖反转原则
  • 客户端不需要知道都有哪些策略类,符合最小知识原则
缺点
  • 策略模式,当策略算法太多时,会造成很多的策略类
  • 客户端不知道有哪些策略类,不能决定使用哪个策略类,这点可以通过封装common公共包解决,也可以考虑使IOC容器依赖注入的方式来解决。

以下是订单来源策略类的一部分,不得不说策略类确实比较多。
在这里插入图片描述

总结:

凡事都有他的两面性,if-else多层嵌套和也都有其各自的优缺点:

if-else的有点就是简单,想快速迭代功能,逻辑嵌套少且不会持续增加,if-else更好些,缺点也是显而易见,代码臃肿繁琐不便于维护。

策略模式 将各个场景的逻辑剥离出来维护,同一抽象类有多个子类,需要使用if-else 或者 switch-case 来选择具体子类时,建议选策略模式,他的缺点就是会产生比较多的策略类文件。

两种实现方式各有利弊,如何选择还是要依据具体业务场景,还是那句话设计模式不是为了用而用,一定要用在最合适的位置。


今天就说这么多,如果本文对您有一点帮助,希望能得到您一个点赞👍哦

您的认可才是我写作的动力!

小福利:

通过合法手段,获取到一些极客付费课程 ,嘘~,免费 送给小伙伴们。公众号回复【极客】自行领取

整理了一些Java方面的架构、面试资料,有需要的小伙伴可以关注公众号【程序员内点事

这篇关于如何优雅的用策略模式,取代臃肿的 if-else 嵌套,看这篇就够了的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/184435

相关文章

Java并发编程之如何优雅关闭钩子Shutdown Hook

《Java并发编程之如何优雅关闭钩子ShutdownHook》这篇文章主要为大家详细介绍了Java如何实现优雅关闭钩子ShutdownHook,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起... 目录关闭钩子简介关闭钩子应用场景数据库连接实战演示使用关闭钩子的注意事项开源框架中的关闭钩子机制1.

Spring Boot中JSON数值溢出问题从报错到优雅解决办法

《SpringBoot中JSON数值溢出问题从报错到优雅解决办法》:本文主要介绍SpringBoot中JSON数值溢出问题从报错到优雅的解决办法,通过修改字段类型为Long、添加全局异常处理和... 目录一、问题背景:为什么我的接口突然报错了?二、为什么会发生这个错误?1. Java 数据类型的“容量”限制

SpringBoot基于配置实现短信服务策略的动态切换

《SpringBoot基于配置实现短信服务策略的动态切换》这篇文章主要为大家详细介绍了SpringBoot在接入多个短信服务商(如阿里云、腾讯云、华为云)后,如何根据配置或环境切换使用不同的服务商,需... 目录目标功能示例配置(application.yml)配置类绑定短信发送策略接口示例:阿里云 & 腾

Nginx location匹配模式与规则详解

《Nginxlocation匹配模式与规则详解》:本文主要介绍Nginxlocation匹配模式与规则,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、环境二、匹配模式1. 精准模式2. 前缀模式(不继续匹配正则)3. 前缀模式(继续匹配正则)4. 正则模式(大

redis过期key的删除策略介绍

《redis过期key的删除策略介绍》:本文主要介绍redis过期key的删除策略,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录第一种策略:被动删除第二种策略:定期删除第三种策略:强制删除关于big key的清理UNLINK命令FLUSHALL/FLUSHDB命

Java实现优雅日期处理的方案详解

《Java实现优雅日期处理的方案详解》在我们的日常工作中,需要经常处理各种格式,各种类似的的日期或者时间,下面我们就来看看如何使用java处理这样的日期问题吧,感兴趣的小伙伴可以跟随小编一起学习一下... 目录前言一、日期的坑1.1 日期格式化陷阱1.2 时区转换二、优雅方案的进阶之路2.1 线程安全重构2

使用Python实现一个优雅的异步定时器

《使用Python实现一个优雅的异步定时器》在Python中实现定时器功能是一个常见需求,尤其是在需要周期性执行任务的场景下,本文给大家介绍了基于asyncio和threading模块,可扩展的异步定... 目录需求背景代码1. 单例事件循环的实现2. 事件循环的运行与关闭3. 定时器核心逻辑4. 启动与停

基于Python实现读取嵌套压缩包下文件的方法

《基于Python实现读取嵌套压缩包下文件的方法》工作中遇到的问题,需要用Python实现嵌套压缩包下文件读取,本文给大家介绍了详细的解决方法,并有相关的代码示例供大家参考,需要的朋友可以参考下... 目录思路完整代码代码优化思路打开外层zip压缩包并遍历文件:使用with zipfile.ZipFil

浅析Java中如何优雅地处理null值

《浅析Java中如何优雅地处理null值》这篇文章主要为大家详细介绍了如何结合Lambda表达式和Optional,让Java更优雅地处理null值,感兴趣的小伙伴可以跟随小编一起学习一下... 目录场景 1:不为 null 则执行场景 2:不为 null 则返回,为 null 则返回特定值或抛出异常场景

SpringRetry重试机制之@Retryable注解与重试策略详解

《SpringRetry重试机制之@Retryable注解与重试策略详解》本文将详细介绍SpringRetry的重试机制,特别是@Retryable注解的使用及各种重试策略的配置,帮助开发者构建更加健... 目录引言一、SpringRetry基础知识二、启用SpringRetry三、@Retryable注解