月下无限连？拒绝无休止switch！

拒绝无休止switch

---

 

一、前言

　　前天碰到个需求，其实很简单，就是Excel导入，Excel模板长下面这样：

 　　

 

 

　　按我平常的逻辑是这样做的：

• 　　用文件输入流读取Excel，根据Excel的版本生成不同的对象，比如XSSFWorkbook或是HSSFWorkbook
•        new一个工作簿，读取内容
•        按行遍历，按cell单元格读取
•        读取到值后，根据业务逻辑进行处理，最后存入entity

　　这个需求按这个逻辑下来，循环取值的代码是这样的：

　　

 1 if (CollectionUtils.isNotEmpty(rowList)) {
 2     List<DtTableCheck> data = Lists.newArrayList();
 3     Map<String, String> paramValueMap;
 4     for (int i = 0; i < rowList.size(); i++) {
 5         paramValueMap = Maps.newLinkedHashMap();
 6         DtTableCheck dtc = new DtTableCheck();
 7         for (Entry<String, String> entry : rowList.get(i).entrySet()) {
 8             switch (entry.getKey().trim()) {
 9                 case "检查编号":
10                     //一堆业务处理
11                 case "数据库":
12                     //一堆业务处理
13                 case "表":
14                     //一堆业务处理
15                 case "限制条件":
16                     //一堆业务处理
17                 case "检查规则":
18                     //一堆业务处理
19                 case "参数1":
20                     //一堆业务处理
21                 case "参数2":
22                     //一堆业务处理
23                 case "参数3":
24                     //一堆业务处理
25                 case "参数4":
26                     //一堆业务处理
27             }
28         }
29         data.add(dtc);
30     }

注：原先的代码过于丑陋，所以用了我司封装的方法，将Excel内容读取到一个list中，再循环读取，可以看到代码依然冗长

　　这样做有一个问题，如果Excel模板变动或是业务逻辑变动，会牵一发而动全身，后端代码都要改，而且这样的代码可维护性极差，典型的面向过程编程。

　　于是，趁着周末，借助策略模式与工厂模式的思想，赶紧重构了代码。

---

 

二、重构

　　代码中重复的操作是频繁的根据Excel单元格名称去switch不同的处理逻辑，那我们把它抽离出来，即

　　

1 /**
2  * 解析Excel数据
3  * @Author Cone
4  * @Date 2019/12/7 12:39
5  */
6 public interface dealExcel {
7 
8     void deal(Map.Entry<String, String> entry, DtTableCheck dtc);
9 }

 

　　传入map中的一个要素，和需要操作的entity，具体的业务处理由不同的实现类去做。

　　接下来我们写一个工厂，用来返回不同的实现类：

　　

 1 /**
 2  * @Author Cone
 3  * @Date 2019/12/7 12:49
 4  */
 5 public class dealFactory {
 6 
 7     private static Map<String, dealExcel> dealMaps = Maps.newConcurrentMap();
 8 
 9     public static dealExcel create(String name) {
10         return dealMaps.get(name);
11     }
12 
13     public static void register(String name, dealExcel de) {
14         dealMaps.put(name, de);
15     }
16     
17 }

 

　　dealMaps用来保存字段名称（比如检查编号、数据库、表等）和对应的操作实现类，create()方法根据传入的字段名称返回对应的实现类，register()方法则将字段名称与实现类保存到dealMaps中供我们调用。

　　这样听起来好像没什么问题，但是我什么时候注册这个实现类到dealMaps中去呢？我们以一个实现类来举例：

　　

 1 /**
 2  * 处理限制条件字段
 3  * @Author Cone
 4  * @Date 2019/12/7 13:16
 5  */
 6 @Service
 7 public class dealQueryCondition implements dealExcel, InitializingBean {
 8     @Override
 9     public void deal(Map.Entry<String, String> entry, DtTableCheck dtc) {
10         dtc.setQueryCondition(null == entry.getValue() ? null : entry.getValue().trim());
11     }
12 
13     @Override
14     public void afterPropertiesSet() throws Exception {
15         dealFactory.register("限制条件", this);
16     }
17 }

　　这个实现类用来处理 Excel中 “限制条件”这一字段，我们在deal()方法中去完成具体的处理逻辑。接下来重点来了，可以看到，这个类还实现了一个接口，即InitializingBean，它是Spring提供的，这个接口里面有一个方法afterPropertiesSet()，用来做属性初始化后的相关操作，凡是继承该接口的类，在bean的属性初始化后，都会执行该方法，我们这里将实现类注册进去。

　　接下来就很简单了，只需要根据业务去完成实现类即可。这样改造完后，程序的调用是这样的：

　　

 1 List<Map<String, String>> rowList = ExcelHelper.readExcelSheet(file.getPath());
 2 if (CollectionUtils.isNotEmpty(rowList)) {
 3 
 4     for (int i = 0; i < rowList.size(); i++) {
 5         DtTableCheck dtc = new DtTableCheck();
 6         for (Entry<String, String> entry : rowList.get(i).entrySet()) {
 7             dealExcel de = dealFactory.create(entry.getKey());
 8             de.deal(entry, dtc);
 9         }
10         
11     }
12     
13 }

　　rowList即为Excel中的数据，数据按行存入list，每一行的数据被放入map中，类似这样：

　　

1 [
2   "检查编号":value,
3   "数据库":value,
4   "限制条件":value          
5 ]

 

　　改造后的效果不用我多说了。

---

 

三、结语

　　我之所以要改造原有代码是因为这个需求在不断变化，模板也在调整，但是如果Excel本来就2,3个字段，或者业务变动不大，那我觉得就没有必要做改造了，改造成本，开发效率需要自己去权衡。运用设计模式应该让代码更好维护，而不是更糟，对吧。