干掉if else!试试这三种设计模式,优化代码贼顺手!

点击上方“芋道源码”,选择“设为星标

管她前浪,还是后浪?

能浪的浪,才是好浪!

每天 10:33 更新文章,每天掉亿点点头发...

源码精品专栏

 

cc504a3dca77b1c72938a0c7f393b9f7.png


前言

在原有代码基础上,如何一步步通过设计模式去优化代码?日常工作中,我们用得最多的设计模式,就是策略模式、工厂模式和模板方法模式 啦。最近刚好用这几种模式优化了代码,所以今天跟大家聊聊,我是怎么优化的,思路是怎么样的。希望本文对大家有帮助哈

  1. 优化前伪代码的流程

  2. 策略模式是如何应用进去的

  3. 工厂设计模式是怎么使用的

  4. 模板方法模式又是怎么应用进去的。

  5. 唠叨几句

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。

项目地址:https://github.com/YunaiV/ruoyi-vue-pro

1. 优化前伪代码流程

大家先看下,优化前,原有代码的大概逻辑哈。代码如下:

class Parameter{
    int pageSize;
    int pageNo;
    int reqNum;
    //其他参数。
}

//逻辑处理,是否命中客群
boolean isMarketHit(Parameter dto){
    //如果是企业客群类型
    if(dto.type == 'enterprise'){
       
       //开关关闭不请求
       if(isEnterpriseSwitchClose){
          return false;           
       }
       
        //请求只有一条记录的话
        if(dto.reqNum==1){
            //调用大数据的点查接口
            return singleRemoteEOIinvoke(dto); 
            
            //请求超过一条的话
        }else if(dto.reqNum>1){
        
            //调用大数据的批量接口
            return batchRemoteEOIinvoke(dto);    
        }
        
        //如果是市场营销类型
    }else if(dto.type=='market_list'){
    
      //开关关闭不请求
       if(isMarketListSwitchClose){
          return false;           
       }
        //请求只有一条记录的话
        if(dto.reqNum==1){
            //调用营销的点查接口
            return singleRemoteMarketinvoke(dto);  
           
          //请求超过一条的话
        }else if(dto.reqNum>1){
            //调用营销的批量接口
            return batchRemoteMarketinvoke(dto);    
        }
    }
}

这个代码可能存在哪些问题呢

  • 如果if分支变多的话,代码就会变得臃肿

  • 如果你需要接入一种新的类型,只能在源代码修改

说得专业一点点,就是以上代码,违背了面向对象的开闭原则和单一原则

  • 开闭原则:(对于扩展是开放的,对于修改是封闭的) ,增加或者删除某个逻辑,都需要修改原来的代码

  • 单一原则:(规定一个类应该只有一个发生变化的原因) ,修改任何类型的分支逻辑代码,都需要修改当前类的代码

基于微服务的思想,构建在 B2C 电商场景下的项目实战。核心技术栈,是 Spring Boot + Dubbo 。未来,会重构成 Spring Cloud Alibaba 。

项目地址:https://github.com/YunaiV/onemall

2. 策略模式是如何应用进去的

大家是否还记得,如果代码中有多个if...else等条件分支,并且每个条件分支,可以封装起来替换的,我们就可以使用策略模式 来优化。

回忆一下,什么是策略模式 呢?

策略模式定义了算法族,分别封装起来,让它们之间可以相互替换 ,此模式让算法的变化独立于使用算法的的客户。这个策略模式的定义是不是有点抽象呢?打个通俗易懂的比喻:

假设你跟不同性格类型的小姐姐约会,要用不同的策略,有的请电影比较好,有的则去吃小吃效果不错,有的去逛街买买买最合适。当然,目的都是为了得到小姐姐的芳心,请看电影、吃小吃、逛街就是不同的策略。

策略模式针对一组算法,将每一个算法封装到实现共同接口的不同独立的类中,从而使得它们可以相互替换。策略模式我们一般是怎么定义的呢?

  • 一个接口或者抽象类,里面两个方法(一个方法匹配类型,一个可替换的逻辑实现方法)

  • 不同策略的差异化实现(就是说,不同策略的实现类)

所以,对于原有的伪代码流程 ,我们就可以定义企业客群类型的策略实现类 ,和市场营销类型的策略实现类 。这两个策略实现类都实现了两个方法,一个方法是匹配类型的,就是返回原始代码if...else条件判断的类型 ;然后另外个方法,就是if...else条件的实现内容。代码如下:

//一个接口
interface IGroupLabelStrategyService {

    //这个方法对应策略实现类的具体实现
    boolean processBiz(Parameter dto);
    
    //这个方法就是策略类的类型,也就是对应```if...else```条件判断的类型
    String getType();
} 

//企业客群类型的策略实现类
EnterpriseGroupLablelStrategyServiceImpl implements IGroupLabelStrategyService{
    
    //对应企业客群类型的条件分支里面的实现
    boolean processBiz(Parameter dto){
    
         //开关关闭不请求
       if(isEnterpriseSwitchClose){
          return false;           
       }
      
        //请求只有一条记录的话
        if(dto.reqNum==1){
            //调用大数据的点查接口
            return singleRemoteEOIinvoke(dto); 
            
            //请求超过一条的话
        }else if(dto.reqNum>1){
        
            //调用远程大数据批量接口
            return batchRemoteEOIinvoke(dto);    
        }
        
     }
     
    //对应企业类型
    String getType(){
       return "enterprise";
    }
}

//市场营销类型的策略实现类
MarketListGroupLablelStrategyServiceImpl implements IGroupLabelStrategyService{

     //对应市场营销类型的条件分支里面的实现
     boolean processBiz(Parameter dto){
     
       //开关关闭不请求
       if(isMarketListSwitchClose){
          return false;           
       }
       
        //请求只有一条记录的话
        if(dto.reqNum==1){
            //调用营销点查接口
            return singleRemoteMarketinvoke(dto);  
           
          //请求超过一条的话
        }else if(dto.reqNum>1){
            //调用营销批量接口
            return batchRemoteMarketinvoke(dto);    
        }
        
      }
      
      String getType(){
         return "market_list";
       }
}

3. 工厂设计模式是怎么使用的

每个策略现在都实现好了,不同策略的实现类怎么交给spring管理呢?

我们可以实现ApplicationContextAware接口,把策略的实现类注入到一个map,然后根据请求方不同的策略请求类型,去实现不同的调用嘛,其实就是类似于工厂模式 的思想啦。代码如下:

@Component
public class GroupLabelStrategyServiceFactory implements ApplicationContextAware{

    //存放对应的类型和实现类
    private Map<String, IGroupLabelStrategyService> map = new ConcurrentHashMap<>();
    
    //策略实现类注入到map
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        Map<String, IGroupLabelStrategyService> tempMap = applicationContext.getBeansOfType(IGroupLabelStrategyService.class);
        
        tmepMap.values().forEach(strategyService -> map.put(strategyService.getType(), strategyService));
    }
    
    //工厂方法
    public boolean processBiz(ParamDTO dto){
    
        //根据不同类型,获取不同的实现类
        IGroupLabelStrategyService groupLabelStrategyService= map.get(dto.getType());
        
        if (batchGroupLabelJudgeService != null) {
            return groupLabelStrategyService.processBiz(dto);
        }
        return false;     
     } 
}

有了策略模式+工厂方法模式后,我们伪代码流程简化成这样啦:

class Parameter{
    int pageSize;
    int pageNo;
    int reqNum;
    //其他参数。
}

boolean isMarketHit(Parameter dto){
  //直接调用工厂类就可以啦,其他逻辑处理已经在策略实现类里面了。
  return groupLabelStrategyServiceFactory.processBiz(dto);
}

4. 模板方法模式又是怎么应用进去的

小伙伴们,细心回头观察下原先的伪代码流程,会发现一个共性的代码流程,就是先开关控制,然后根据请求数量决定走单笔调用还是批量调用

这就可以使用模板方法 继续优化了。所谓模板方法模式,其实就是:

定义一个操作中的算法的骨架流程 ,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。它的核心思想就是:定义一个操作的一系列步骤,对于某些暂时确定不下来的步骤,就留给子类去实现,这样不同的子类就可以定义出不同的步骤。

为了通俗易懂一点,打个比喻:

追女朋友要先“牵手”,再“拥抱”,再“接吻”, 再“拍拍..额..手”。至于具体你用左手还是右手牵,无所谓,但是整个过程,定了一个流程模板,按照模板来就行。

模板方法使用比较简单:

  • 一个抽象类,定义骨架流程(抽象方法放一起)

  • 确定的共同方法步骤,放到抽象类(去除抽象方法标记)

  • 不确定的步骤,给子类去差异化实现

我们只需要把开关控制接口,单笔远程调用、批量远程调用这个通用共性的流程,定义到模板抽象类就好啦。代码如下:

public abstract  AbstractGroupLabelJudgeTemplate implements IGroupLabelStrategyService{
         //模板骨架
         public boolean processBiz(Parameter dto){
              if(isSwitchClose){
                 return false;
              }
             if(dto.reqNum==1){
                 return singleRemote(dto);
             }else if(dto.reqNum>1){
                 return batchRemote(dto);
            }
         }
       //开关由子类控制
        abstract boolean isSwitchClose();
        //单笔远程调用,由子类控制
        astract boolean singleRemote(dto);
        //批量远程调用,由子类控制
        astract boolean batchRemote(dto);
}

不同的策略子类自己控制开关,和控制不同接口的调用即可。

EnterpriseGroupLablelStrategyServiceImpl extends AbstractGroupLabelJudgeTemplate{
     boolean isSwitchClose(){
         //企业客群开关
     }
     boolean singleRemote(ParamDTO dto){
        //企业客群单笔调用     
        return singleRemoteEOIinvoke(dto);    
    }
    boolean batchRemote(ParamDTO dto){
      //企业客群批量调用   
      return batchRemoteEOIinvoke(dto);
   }        
}
MarketListGroupLablelStrategyServiceImpl extends AbstractGroupLabelJudgeTemplate{
     boolean isSwitchClose(){
         //营销客群开关
     }
     boolean singleRemote(ParamDTO dto){
        //营销客群单笔调用     
        return singleRemoteMarketinvoke(dto);    
    }
    boolean batchRemote(ParamDTO dto){
      //营销客群批量调用   
      return batchRemoteMarketinvoke(dto);
   }        
}

5. 唠叨几句

策略模式、工厂模式和模板方法模式这三种设计模式,是日常开发用得最多的。本文呢,也是阐述了我是如何在原有代码上,抽取出设计模式的,大家可以应用到自己的工作中去哈。



欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢

63d5e89f1d20fce2b910deed73be86b8.png

已在知识星球更新源码解析如下:

415b1f94711fab9e26e721e116d1a2d6.png

6cc83bac656abe2c8e2a59ceecd63aaa.png

e00f1e1032b4915f39cde0bc42e7936d.png

2407dd0ae0fc9250654293e12a1bdf00.png

最近更新《芋道 SpringBoot 2.X 入门》系列,已经 101 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。

获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。

文章有帮助的话,在看,转发吧。
谢谢支持哟 (*^__^*)
  • 3
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值