现已放在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
 */
@Service
public 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
@Slf4j
public 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