来源:http://t.cn/E9beQIN
需求
这里虚拟一个业务需求,让大家容易理解。假设有一个订单系统,里面的一个功能是根据订单的不同类型作出不同的处理。
订单实体:
service 接口:
传统实现
根据订单类型写一堆的 if else:
策略模式实现
利用策略模式,只需要两行即可实现业务逻辑:
可以看到上面的方法中注入了 HandlerContext,这是一个处理器上下文,用来保存不同的业务处理器,具体在下文会讲解。我们从中获取一个抽象的处理器 AbstractHandler,调用其方法实现业务逻辑。
现在可以了解到,我们主要的业务逻辑是在处理器中实现的,因此有多少个订单类型,就对应有多少个处理器。以后需求变化,增加了订单类型,只需要添加相应的处理器就可以,上述 OrderServiceV2Impl 完全不需改动。
我们先看看业务处理器的写法:
首先每个处理器都必须添加到 spring 容器中,因此需要加上 @Component 注解,其次需要加上一个自定义注解 @HandlerType,用于标识该处理器对应哪个订单类型,最后就是继承 AbstractHandler,实现自己的业务逻辑。
自定义注解 @HandlerType:
抽象处理器 AbstractHandler:
自定义注解和抽象处理器都很简单,那么如何将处理器注册到 spring 容器中呢?
具体思路是:
1、扫描指定包中标有 @HandlerType 的类;
2、将注解中的类型值作为 key,对应的类作为 value,保存在 Map 中;
3、以上面的 map 作为构造函数参数,初始化 HandlerContext,将其注册到 spring 容器中;
我们将核心的功能封装在 HandlerProcessor 类中,完成上面的功能。
HandlerProcessor:
ClassScanner:扫描工具类源码
HandlerProcessor 需要实现 BeanFactoryPostProcessor,在 spring 处理 bean 前,将自定义的 bean 注册到容器中。
核心工作已经完成,现在看看 HandlerContext 如何获取对应的处理器:
HandlerContext:
BeanTool:获取 bean 工具类
#getInstance
方法根据类型获取对应的 class,然后根据 class 类型获取注册到 spring 中的 bean。
最后请注意一点,HandlerProcessor 和 BeanTool 必须能被扫描到,或者通过 @Bean 的方式显式的注册,才能在项目启动时发挥作用。
总结
利用策略模式可以简化繁杂的 if else 代码,方便维护,而利用自定义注解和自注册的方式,可以方便应对需求的变更。本文只是提供一个大致的思路,还有很多细节可以灵活变化,例如使用枚举类型、或者静态常量,作为订单的类型,相信你能想到更多更好的方法。