现已放在gitee上,可以不下载直接参考一下即: https://gitee.com/zhang-xiao-xiang/zxx-pattern
日常碰到的业务概述 登录类型,支付类型,供应商渠道,不同等级会员享受的优惠券价格不一样,等等业务判断,大量if else导致拓展(侧重新增)极其困难,维护(侧重修改)自然是改起来头痛(其实一个类型的增加[拓展一个类型]往往对应这个类型的增删改查CRUD[维护]),比如业务一开始一个简单的登录,往往做一个电话号码和验证码登录的方式或者账号密码登录方式,后来随着业务的增加或者提高用户体验,那么需要拓展(新增一种)三方登录,比如新增微信登录,支付宝登录,甚至抖音登录,一大堆,你要根据登录方式来处理,那就有点恼火吧,支付方式也是同样的问题,我们可以发现一个规律,凡是可以枚举的业务,往往都需要使用设计模式才能更好的解决,比如策略模式(往往搭配工厂模式使用更配哦),水来土掩,兵来将挡,这思想和高中数学中的分类讨论思想一模一样.遇事不要慌,因为还有dang中央.所以,我们就打个栗子,举个比方,更加形象一点由于太多的策略模式时根据顾客VIP等级不同,得到的商品价格不一样的例子,这里还是换个汤,顺便更新了一下博客,以星座自我介绍(根据星座的类型不同,返回不同的信息)为例子,结合springboot实际感受一下在实战时的策略模式样子
先来个直观的对比一睹为快(放大效果更佳)未使用时:我们经常直接在业务层开始了if else的常规操作
使用策略模后时:注意看一下描述
简单做个结论:这里不是说代码量减少了哈,而是说需要新增或者修改的时候,维护难度就不一样了
策略模式经过对比分析,发现之所以出现if else和分支,还是少了面向接口编程的思想,做一件事情,假如实现方式多样,那么第一个想到的就是抽象出事情,不管是抽象类也好,做成接口也罢,反正尽量朝着多态的方向去就对了.if else做的事情就是在处理对应星座的描述信息,所以把要描述信息抽取成一个策略方法
1:面向接口编程,这里抽取业务方法(这里有个2个方法是为了对比哈,第二个就是策略模式抽取的)
package com.zhang.zxx.pattern.strategy.service;/** * BusinessService:业务服务层 * * @author zhangxiaoxiang * @date 2021/07/18 */public interface BusinessService { /** * 根据星座类型获取星座详情 * @param type 星座类型 枚举 * @return 星座描述 */ Object getInfo(Integer type); /** * 根据星座类型获取星座详情 * @param type 星座类型 枚举 * @return 星座描述 */ Object getInfoWithStrategy(Integer type);}再来一个接口 ,这里是处理策略的方法,不是业务的层面的方法
package com.zhang.zxx.pattern.strategy;import java.util.Map;/** * StrategyService:定义策略接口,,这里可以理解为if(满足条件fetchKey){执行execute的策略 } * 联系后面的类可以感觉这里相当于抽象了个map出来 * * @author zhangxiaoxiang * @date 17/7/2021 */public interface StrategyService { /** * 匹配策略的key[这个key使用枚举管理最为合理] * * @return key */ Integer fetchKey(); /** * 匹配后具体策略执行 * * @return 结果[这里为了对数据执行策略结果的收集,选择了Map<String, Object>较为通用,当然void或者object也行,根据实际项目来即可] */ Map<String, Object> execute();}2:编写策略接口的实现类,这里举一个实现类就行了,我尽量做到减少篇幅
package com.zhang.zxx.pattern.strategy.strategy;import com.zhang.zxx.pattern.strategy.MyEnum;import com.zhang.zxx.pattern.strategy.StrategyService;import org.springframework.stereotype.Service;import java.util.HashMap;import java.util.Map;/** * FirstStrategyImpl:水瓶座策略类[这里具体策略execute比如为知我介绍] * * @author zhangxiaoxiang * @date 2021/07/18 */@Servicepublic class AquariusStrategyImpl implements StrategyService { /** * 匹配策略的key[这个key使用枚举管理最为合理] * * @return key */ @Override public Integer fetchKey() { //水瓶座策略标识 return MyEnum.AQUARIUS.getNum(); } /** * 匹配后具体策略执行 * * @return 结果[这里为了对数据执行策略结果的收集, 选择了Map<String, Object>较为通用,当然void或者object也行,根据实际项目来即可] */ @Override public Map<String, Object> execute() { Map<String, Object> map=new HashMap<>(16); map.put("name","我是水瓶座"); map.put("birthTime","1月20日~2月18日"); map.put("luckyNumber","3、5、7"); return map; }}3:即便有了策略接口和对应的实现类,但是仍然不能使用,此时需要一个策略辅助或者叫做处理类来帮忙,像一个工厂一样的类,其实就是工程模式的实现哈
package com.zhang.zxx.pattern.strategy;import lombok.extern.slf4j.Slf4j;import org.springframework.beans.BeansException;import org.springframework.beans.factory.InitializingBean;import org.springframework.context.ApplicationContext;import org.springframework.context.ApplicationContextAware;import org.springframework.stereotype.Component;import java.util.Map;import java.util.concurrent.ConcurrentHashMap;/** * StrategyHandler:策略处理类[可以理解为策略工厂类] * * @author zhangxiaoxiang * @date 18/7/2021 */@Component@Slf4jpublic class StrategyHandler implements InitializingBean, ApplicationContextAware { /** * 存放策略的map,可以理解为策略的注册中心 */ private final Map<Integer, StrategyService> strategyServiceMap = new ConcurrentHashMap<>(16); /** * spring的上下文 */ private ApplicationContext applicationContext; /** * 将StrategyService的类都按照定义好的规则（fetchKey），放入strategyServiceMap中 */ @Override public void afterPropertiesSet() { //初识化把所有的策略bean放进ioc,用于使用的时候获取 Map<String, StrategyService> matchBeans = applicationContext.getBeansOfType(StrategyService.class); //策略注入的bean做key,策略实现类做value matchBeans.forEach((key, value) ->{ strategyServiceMap.put(value.fetchKey(), value); log.info("初始化策略模式的键值对 key={},value={}",key,value); }); } /** * 注入applicationContext * * @param applicationContext ac * @throws BeansException e */ @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext = applicationContext; } /** * 通过key获取对应的策略实现 * * @param key key(String类型或者整形都行,保持和策略接口一致就行) * @return strategyService */ public StrategyService getStrategy(Integer key) { if (null==strategyServiceMap.get(key)) { //默认策略 return strategyServiceMap.get(0); } return strategyServiceMap.get(key); }}其实到这里已经完了,结构大致如图
如果觉得文章有点乱还是建议看完整代码吧,确实要全部展现出来篇幅太大哈
小结和抛出一些观点:有个缺点就是类膨胀,就是策略类太多的情况下,这个类就太多了,当然有方式处理,但是结合实际,最终还是妥协选择类膨胀,因为这个也不算什么大缺点,可以忽略.其实java的JDK8的函数式编程和Lambda表达式(简化匿名类等写法)可以让策略模式更加优雅,其实就是相当于JDK8新特性是把23中设计模式更加抽象的方式用在新语法上了,符合时代潮流,拓展java的函数式编程领域,可以大概参考哈新特性 https://zhangxiaoxiang.blog.csdn.net/article/details/100638661