前言
大家好，我是捡田螺的小男孩。
本文是后端思维专栏的第三篇哈，本文内容就是：在原有代码基础上，如何一步步通过设计模式去优化代码？日常工作中，我们用得最多的设计模式，就是策略模式、工厂模式和模板方法模式啦。最近刚好用这几种模式优化了代码，所以今天跟大家聊聊，我是怎么优化的，思路是怎么样的。希望本文对大家有帮助哈。
- 优化前伪代码的流程
- 策略模式是如何应用进去的
- 工厂设计模式是怎么使用的
- 模板方法模式又是怎么应用进去的。
- 唠叨几句
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分支变多的话，代码就会变得臃肿
- 如果你需要接入
一种新的类型，只能在源代码修改
说得专业一点点，就是以上代码，违背了面向对象的开闭原则和单一原则。
- 开闭原则：（对于扩展是开放的，对于修改是封闭的），增加或者删除某个逻辑，都需要修改原来的代码
- 单一原则：（规定一个类应该只有一个发生变化的原因），修改任何类型的分支逻辑代码，都需要修改当前类的代码
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. 唠叨几句
策略模式、工厂模式和模板方法模式这三种设计模式，是日常开发用得最多的。本文呢，也是阐述了我是如何在原有代码上，抽取出设计模式的。
