被迫重构代码，这次我干掉了 if-else

heatdog

发布于 2022-12-21 10:46

浏览

0收藏

最近公司貌似融到资了！开始发了疯似的找渠道推广，现在终于明白为啥前一段大肆的招人了，原来是在下一盘大棋，对员工总的来看是个好事，或许是时候该跟boss提一提涨工资的话题了。

不过，涨工资还没下文，随之而来的却是一车一车的需求，每天都有新渠道接入，而且每个渠道都要提供个性化支持，开发量陡增。最近都没什么时间更文，准点下班都成奢望了！由于推广渠道的激增，而每一个下单来源在下单时都做特殊的逻辑处理，可能每两天就会加一个来源，已经把之前的下单逻辑改的面目全。出于长远的考虑，我决定对现有的逻辑进行重构，毕竟长痛不如短痛。

传统的实现方式

我们看下边的伪代码，大致就是重构前下单逻辑的代码，由于来源比较少，简单的做if-else逻辑判断足以满足需求。

现在每种订单来源的处理逻辑都有几百行代码，看着已经比较臃肿，可我愣是迟迟没动手重构，一方面业务方总像催命鬼一样的让你赶工期，想快速实现需求，这样写是最快；另一方面是不敢动，面对古董级代码，还是想求个安稳。

但这次来源一下子增加几十个，再用这种方式做已经无法维护了，想象一下那种臃肿的if-else代码，别说开发想想都头大！

public class OrderServiceImpl implements IOrderService {
    @Override
    public String handle(OrderDTO dto) {
        String type = dto.getType();
        if ("1".equals(type)) {
            return "处理普通订单";
        } else if ("2".equals(type)) {
            return "处理团购订单";
        } else if ("3".equals(type)) {
            return "处理促销订单";
        }
        return null;
    }
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

策略模式的实现方式

思来想去基于当前业务场景重构，还是用策略模式比较合适，它是oop中比较著名的设计模式之一，对方法行为的抽象。

策略模式定义了一个拥有共同行为的算法族，每个算法都被封装起来，可以互相替换，独立于客户端而变化。

一、策略模式的使用场景：

针对同一问题的多种处理方式，仅仅是具体行为有差别时；
需要安全地封装多种同一类型的操作时；
同一抽象类有多个子类，而客户端需要使用if-else 或者switch-case 来选择具体子类时。

这个是用策略模式修改后代码：

@Component
@OrderHandlerType(16)
public class DispatchModeProcessor extends AbstractHandler{

 @Autowired
 private OrderStencilledService orderStencilledService;
 
 @Override
 public void handle(OrderBO orderBO){
  
  /**
      * 订单完结广播通知(1 - 支付完成)
      */
     orderStencilledService.dispatchModeFanout(orderBO);
  
     /**
      *  SCMS 出库单
      */
     orderStencilledService.createScmsDeliveryOrder(orderBO.getPayOrderInfoBO().getLocalOrderNo());
 }
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.

每个订单来源都有自己单独的逻辑实现类，而每次需要添加订单来源，直接新建实现类，修改@OrderHandlerType(16)的数值即可，再也不用去翻又臭又长的if-lese。

不仅如此在分配任务时，每个人负责开发几种订单来源逻辑，都可以做到互不干扰，而且很大程度上减少了合并代码的冲突。

二、具体的实现过程：

1、定义注解

定义一个标识订单来源的注解@OrderHandlerType

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface OrderHandlerType {
 int value() default 0;
}1.
2.
3.
4.
5.
6.
7.

2、抽象业务处理器

向上抽象出来一个具体的业务处理器

public abstract class AbstractHandler {
 abstract public void handle(OrderBO orderBO);
}1.
2.
3.

3、项目启动扫描 `handler` 入口

@Component
@SuppressWarnings({"unused","rawtypes"})
public class HandlerProcessor implements BeanFactoryPostProcessor {
 
 private String basePackage = "com.ecej.order.pipeline.processor";
 
    public static final Logger log = LoggerFactory.getLogger(HandlerProcessor.class);
 
 @Override
 public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
  
  Map<Integer,Class> map = new HashMap<Integer,Class>();
  
  ClassScaner.scan(basePackage, OrderHandlerType.class).forEach(x ->{
   int type = x.getAnnotation(OrderHandlerType.class).value();
   map.put(type,x);
  });
  
  beanFactory.registerSingleton(OrderHandlerType.class.getName(), map);
  
  log.info("处理器初始化{}", JSONObject.toJSONString(beanFactory.getBean(OrderHandlerType.class.getName())));
 }
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

4、扫描需要用到的工具类

public class ClassScaner {
 private ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver();

 private final List<TypeFilter> includeFilters = new ArrayList<TypeFilter>();

 private final List<TypeFilter> excludeFilters = new ArrayList<TypeFilter>();

 private MetadataReaderFactory metadataReaderFactory = new CachingMetadataReaderFactory(resourcePatternResolver);
 
 /**
  * 添加包含的Fiter
  * @param includeFilter
  */
 public void addIncludeFilter(TypeFilter includeFilter) {
  this.includeFilters.add(includeFilter);
 }

 /**
  * 添加排除的Fiter
  * @param includeFilter
  */
 public void addExcludeFilter(TypeFilter excludeFilter) {
  this.excludeFilters.add(excludeFilter);
 }
 
 /**
  * 扫描指定的包，获取包下所有的Class
  * @param basePackage 包名
  * @param targetTypes 需要指定的目标类型,可以是pojo,可以是注解
  * @return Set<Class<?>>
  */
 public static Set<Class<?>> scan(String basePackage,
   Class<?>... targetTypes) {
  ClassScaner cs = new ClassScaner();
  for (Class<?> targetType : targetTypes){
   if(TypeUtils.isAssignable(Annotation.class, targetType)){
    cs.addIncludeFilter(new AnnotationTypeFilter((Class<? extends Annotation>) targetType));
   }else{
    cs.addIncludeFilter(new AssignableTypeFilter(targetType));
   }
  }
  return cs.doScan(basePackage);
 }
 
 /**
  * 扫描指定的包，获取包下所有的Class
  * @param basePackages 包名,多个
  * @param targetTypes 需要指定的目标类型,可以是pojo,可以是注解
  * @return Set<Class<?>>
  */
 public static Set<Class<?>> scan(String[] basePackages,
   Class<?>... targetTypes) {
  ClassScaner cs = new ClassScaner();
  for (Class<?> targetType : targetTypes){
   if(TypeUtils.isAssignable(Annotation.class, targetType)){
    cs.addIncludeFilter(new AnnotationTypeFilter((Class<? extends Annotation>) targetType));
   }else{
    cs.addIncludeFilter(new AssignableTypeFilter(targetType));
   }
  }
  Set<Class<?>> classes = new HashSet<Class<?>>();
  for (String s : basePackages){
   classes.addAll(cs.doScan(s));
  }
  return classes;
 }
 
 /**
  * 扫描指定的包，获取包下所有的Class
  * @param basePackages 包名
  * @return Set<Class<?>>
  */
 public Set<Class<?>> doScan(String [] basePackages) {
  Set<Class<?>> classes = new HashSet<Class<?>>();
  for (String basePackage :basePackages) {
   classes.addAll(doScan(basePackage));
  }
  return classes;
 }
 
 /**
  * 扫描指定的包，获取包下所有的Class
  * @param basePackages 包名
  * @return Set<Class<?>>
  */
 public Set<Class<?>> doScan(String basePackage) {
  Set<Class<?>> classes = new HashSet<Class<?>>();
  try {
   String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX
     + ClassUtils.convertClassNameToResourcePath(
       SystemPropertyUtils.resolvePlaceholders(basePackage))+"/**/*.class";
   Resource[] resources = this.resourcePatternResolver.getResources(packageSearchPath);
   for (int i = 0; i < resources.length; i++) {
    Resource resource = resources[i];
    if (resource.isReadable()) {
     MetadataReader metadataReader = this.metadataReaderFactory.getMetadataReader(resource);
     if ((includeFilters.size() == 0 && excludeFilters.size() == 0)|| matches(metadataReader)) {
      try {
       classes.add(Class.forName(metadataReader.getClassMetadata().getClassName()));
      } catch (ClassNotFoundException ignore) {}
     }
    }
   }
  } catch (IOException ex) {
   throw new RuntimeException("I/O failure during classpath scanning", ex);
  }
  return classes;
 }
 
 /**
  * 处理 excludeFilters和includeFilters
  * @param metadataReader
  * @return boolean
  * @throws IOException
  */
 private boolean matches(MetadataReader metadataReader) throws IOException {
  for (TypeFilter tf : this.excludeFilters) {
   if (tf.match(metadataReader, this.metadataReaderFactory)) {
    return false;
   }
  }
  for (TypeFilter tf : this.includeFilters) {
   if (tf.match(metadataReader, this.metadataReaderFactory)) {
    return true;
   }
  }
  return false;
 }
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.

5、根据类型实例化抽象类


@Component
public class HandlerContext {

 @Autowired
 private ApplicationContext beanFactory;

 public  AbstractHandler getInstance(Integer type){
  
  Map<Integer,Class> map = (Map<Integer, Class>) beanFactory.getBean(OrderHandlerType.class.getName());
  
  return (AbstractHandler)beanFactory.getBean(map.get(type));
 }
 
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

6、调用入口

我这里是在接受到MQ消息时，处理多个订单来源业务，不同订单来源路由到不同的业务处理类中。


@Component
@RabbitListener(queues = "OrderPipelineQueue")
public class PipelineSubscribe{
 
 private final Logger LOGGER = LoggerFactory.getLogger(PipelineSubscribe.class);
 
 @Autowired
 private HandlerContext HandlerContext;
 
 @Autowired
 private OrderValidateService orderValidateService;
 
    @RabbitHandler
    public void subscribeMessage(MessageBean bean){
     
     OrderBO orderBO = JSONObject.parseObject(bean.getOrderBO(), OrderBO.class);
     
     if(null != orderBO &&CollectionUtils.isNotEmpty(bean.getType()))
     {
      for(int value:bean.getType())
      {
          AbstractHandler handler = HandlerContext.getInstance(value);
          handler.handle(orderBO);
      }
  }
 }
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.

接收实体 MessageBean 类代码

public class MessageBean implements Serializable {
    private static final long serialVersionUID = 5454831432308782668L;
    private String cachKey;
    private List<Integer> type;
    private String orderBO;

    public MessageBean(List<Integer> type, String orderBO) {
        this.type = type;
        this.orderBO = orderBO;
    }
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

以上设计模式方式看着略显复杂，很些小伙伴提出质疑：“你为了个if-else，弄的如此的麻烦，又是自定义注解，又弄这么多类不麻烦吗？” 还有一些小伙伴纠结于性能问题，策略模式的性能可能确实不如if-else。

但我觉得吧增加一点复杂度、牺牲一丢丢性能，换代码的整洁和可维护性还是值得的。不过，一个人一个想法，怎么选还是看具体业务场景吧！

被迫重构代码，这次我干掉了 if-else-鸿蒙开发者社区

策略模式的优缺点

优点

易于扩展，增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合开放封闭原则
避免使用多重条件选择语句，充分体现面向对象设计思想策略类之间可以自由切换，由于策略类都实现同一个接口，所以使它们之间可以自由切换
每个策略类使用一个策略类，符合单一职责原则客户端与策略算法解耦，两者都依赖于抽象策略接口，符合依赖反转原则
客户端不需要知道都有哪些策略类，符合最小知识原则

缺点

策略模式，当策略算法太多时，会造成很多的策略类
客户端不知道有哪些策略类，不能决定使用哪个策略类，这点可以通过封装common公共包解决，也可以考虑使IOC容器和依赖注入的方式来解决。

以下是订单来源策略类的一部分，不得不说策略类确实比较多。

被迫重构代码，这次我干掉了 if-else-鸿蒙开发者社区

总结

凡事都有他的两面性，if-else多层嵌套和也都有其各自的优缺点：

if-else的优点就是简单，想快速迭代功能，逻辑嵌套少且不会持续增加，if-else更好些，缺点也是显而易见，代码臃肿繁琐不便于维护。
策略模式 将各个场景的逻辑剥离出来维护，同一抽象类有多个子类，需要使用if-else 或者switch-case 来选择具体子类时，建议选策略模式，他的缺点就是会产生比较多的策略类文件。

两种实现方式各有利弊，如何选择还是要依据具体业务场景，还是那句话设计模式不是为了用而用，一定要用在最合适的位置。

文章转载自公众号：程序员小富

分类

其他

标签

重构代码

已于2022-12-21 10:46:57修改

51CTO

51CTO博客

51CTO学堂

被迫重构代码，这次我干掉了 if-else

传统的实现方式

策略模式的实现方式

一、策略模式的使用场景：

二、具体的实现过程：

1、定义注解

2、抽象业务处理器

3、项目启动扫描 `handler` 入口

4、扫描需要用到的工具类

5、根据类型实例化抽象类

6、调用入口

策略模式的优缺点

优点

缺点

总结

目录

订阅鸿蒙技术特刊，精选内容抢先看

51CTO

51CTO博客

51CTO学堂

被迫重构代码，这次我干掉了 if-else

传统的实现方式

策略模式的实现方式

一、策略模式的使用场景：

二、具体的实现过程：

1、定义注解

2、抽象业务处理器

3、项目启动扫描 ​​handler​​ 入口

4、扫描需要用到的工具类

5、根据类型实例化抽象类

6、调用入口

策略模式的优缺点

优点

缺点

总结

目录

订阅鸿蒙技术特刊，精选内容抢先看

3、项目启动扫描 `handler` 入口